overview/working-with-objects/object-management/

kubectl命令行工具支持几种不同的方法来创建和管理kubernetes对象。本文概述了不同的方法。阅读Kubectl book 了解kubectl管理对象的详细信息。

Management techniques

Imperative commands 命令式

当使用命令方式时，用户直接操作集群中的活动对象。用户将操作作为参数或标志提供给kubectl命令。

这是在集群中启动或运行一次性任务的最简单方法。由于此技术直接在活动对象上操作，因此它不提供以前配置的历史记录。

例子

Run an instance of the nginx container by creating a Deployment object:

通过Deployment object创建运行一个nginx实例

kubectl run nginx --image nginx

用不同的语法做同样的事情(另一种语法):

kubectl create deployment nginx --image nginx

Trade-offs 权衡

与对象配置相比的优势:

• 命令式易学,易记.
• 命令只需要一个步骤就可以对集群进行更改.

与对象配置相比的缺点:

• 没有review过程
• 历史追踪没有.
• 没有记录
• 命令不提供用于创建新对象的模板。

Imperative object configuration 命令对象配置

在 imperative object configuration中, 通过kubectl命令制定操作 (创建, 替换, 等等.), 操作参数必须指定一个至少文件名. 操作的文件必须是yaml或者json格式且是一个对象完整定义

有关对象定义详细信息请查看 API reference 进行参考

Warning: The imperative replace command replaces the existing spec with the newly provided one, dropping all changes to the object missing from the configuration file. This approach should not be used with resource types whose specs are updated independently of the configuration file. Services of type LoadBalancer, for example, have their externalIPs field updated independently from the configuration by the cluster.

命令替换命令用新提供的规范替换现有规范，删除配置文件中缺少的对象的所有更改。此方法不应用于其规范独立于配置文件进行更新的资源类型。例如，loadbalancer类型的服务的externalips字段独立于集群的配置进行更新。

Examples

从指定的文件创建一个对象:

kubectl create -f nginx.yaml

删除两个配置文件中定义的对象:

kubectl delete -f nginx.yaml -f redis.yaml

通过覆盖实时配置更新配置文件中定义的对象：

kubectl replace -f nginx.yaml

Trade-offs 权衡

Advantages compared to imperative commands 与命令行相比的优势:

• 对象配置可以保持在git等版本控制中
• 可以进行集成,更新推送都可对其进行审核.
• Object configuration 提供了创建新对象的模板

与简单命令式对比缺点:

• Object configuration方式需要先了解object schema.
• Object configuration方式需要了解yaml或者json格式语法

Advantages compared to declarative object configuration 与声明性对象配置相比的优势: :

• 命令式对象配置行为更简单、更易于理解。
• 从Kubernetes 1.5版开始，命令式对象配置更加成熟。

Disadvantages compared to declarative object configuration 与声明性对象配置相比的缺点：

• 命令式对象配置最适合于文件，而不是目录。
• 对活动对象的更新必须反映在配置文件中，否则它们将在下一次替换过程中丢失。

Declarative object configuration 声明性对象配置(声明式)

When using declarative object configuration, a user operates on object configuration files stored locally, however the user does not define the operations to be taken on the files. Create, update, and delete operations are automatically detected per-object by kubectl. This enables working on directories, where different operations might be needed for different objects.当使用声明性对象配置时，用户对本地存储的对象配置文件进行操作，但是用户不定义要对文件执行的操作。kubectl会自动为每个对象检测创建、更新和删除操作。这允许在目录上工作，不同的对象可能需要不同的操作。

Note: Declarative object configuration retains changes made by other writers, even if the changes are not merged back to the object configuration file. This is possible by using the patch API operation to write only observed differences, instead of using the replace API operation to replace the entire object configuration.声明性对象配置保留其他编写器所做的更改，即使这些更改未合并回对象配置文件。这可以通过使用“patch”api操作来只写入观察到的差异，而不是使用“replace”api操作来替换整个对象配置。

Examples

Process all object configuration files in the configs directory, and create or patch the live objects. You can first diff to see what changes are going to be made, and then apply--- 处理“configs”目录中的所有对象配置文件，并创建或修补活动对象。您可以先“diff”查看要进行的更改，然后应用：(先对比变化再进行修改)

kubectl diff -f configs/
kubectl apply -f configs/

Recursively process directories(使用递归):

kubectl diff -R -f configs/
kubectl apply -R -f configs/

Trade-offs权衡

Advantages compared to imperative object configuration与命令式对象配置相比的优势:

• 直接对活动对象所做的更改将被保留，即使它们没有合并回配置文件中。

• 声明性对象配置更好地支持在目录上操作和自动检测每个对象的操作类型（创建、修补、删除）。
  Disadvantages compared to imperative object configuration与命令式对象配置相比的缺点：

• 声明性对象配置在意外情况下很难调试和理解结果。

• 使用diff的部分更新创建复杂的合并和修补操作。

What's next

• Managing Kubernetes Objects Using Imperative Commands

• Managing Kubernetes Objects Using Object Configuration (Imperative)

• Managing Kubernetes Objects Using Object Configuration (Declarative)

• Managing Kubernetes Objects Using Kustomize (Declarative)

• Kubectl Command Reference

• Kubectl Book

• Kubernetes API Reference

本作品采用《CC 协议》，转载必须注明作者和本文链接