kubernetes kubectl中的发电机是什么? [英] What are generators in kubernetes kubectl?

问题描述

当我想通过运行kubectl生成yaml时，它表示我应该在命令中表示--generator=something标志.

When I want to generate yaml by running kubectl, it denotes that I should denote --generator=something flag within the command.

例如，要通过kubectl获取部署模板，我应运行以下命令:

For example, to get the deployment template via kubectl, I should run the below command:

kubectl run --generator=deployment/v1beta1 nginx --image=nginx --dry-run -o yaml

在不提及--generator标志的情况下，CLI会以某种方式指出我应该使用适当的值(例如run-pod/v1)来提及generator标志.

Without mentioning --generator flag the CLI states in some kind that I should mention the generator flag with a proper value (e.g. run-pod/v1).

我的问题是，本质上什么是发电机?它有什么作用?它们是某种对象创建模板还是其他?

My question is, what is essentially a generator? What does it do? Are they some sort of object creation templates or something else?

推荐答案

在提交426ef93 ，2016年1月，适用于Kubernetes v1.2.0-alpha.8.

That was introduced in commit 426ef93, Jan. 2016 for Kubernetes v1.2.0-alpha.8.

生成器为:

生成器是kubectl命令，它们根据一组输入(其他资源，标志或两者的组合)生成资源.

Generators are kubectl commands that generate resources based on a set of inputs (other resources, flags, or a combination of both).

生成器的要点是:

• 使用户能够以脚本方式使用kubectl来锁定将来可能会改变的特定行为.
  明确使用生成器将始终保证预期的行为保持不变.
• 对于仅创建以外的方案，可以潜在地扩展生成的资源，这与大多数通用命令支持-f的方式类似.

• to enable users using kubectl in a scripted fashion to pin to a particular behavior which may change in the future.
  Explicit use of a generator will always guarantee that the expected behavior stays the same.
• to enable potential expansion of the generated resources for scenarios other than just creation, similar to how -f is supported for most general-purpose commands.

并且:

生成器命令应遵循以下约定:

Generator commands should obey to the following conventions:

• 应定义一个--generator标志.然后，用户可以选择不同的生成器(如果命令支持它们)(例如，kubectl run当前支持Pod，作业，复制控制器和部署的生成器)，或者在生成器的不同版本之间进行选择，以便用户根据特定的行为进行选择.可能会固定到该版本(例如，kubectl公开当前支持服务生成器的两个不同版本).
• 生成应该与创造脱钩.
  生成器应实现kubectl.StructuredGenerator接口，并且不依赖于眼镜蛇或Factory

• A --generator flag should be defined. Users then can choose between different generators, if the command supports them (for example, kubectl run currently supports generators for pods, jobs, replication controllers, and deployments), or between different versions of a generator so that users depending on a specific behavior may pin to that version (for example, kubectl expose currently supports two different versions of a service generator).
• Generation should be decoupled from creation.
  A generator should implement the kubectl.StructuredGenerator interface and have no dependencies on cobra or the Factory

这篇关于kubernetes kubectl中的发电机是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！