Kubernetes 对象管理
kubectl
命令行工具支持多种不同的方式来创建和管理 Kubernetes 对象。本文档概述了不同的方法。阅读 Kubectl 书籍 以了解使用 Kubectl 管理对象的详细信息。
管理技术
警告
一个 Kubernetes 对象应该只使用一种技术进行管理。对同一个对象混合使用不同的技术会导致未定义的行为。管理技术 | 操作对象 | 推荐环境 | 支持的编写者 | 学习曲线 |
---|---|---|---|---|
命令式命令 | 活动对象 | 开发项目 | 1+ | 最低 |
命令式对象配置 | 单个文件 | 生产项目 | 1 | 中等 |
声明式对象配置 | 文件目录 | 生产项目 | 1+ | 最高 |
命令式命令
当使用命令式命令时,用户直接操作集群中的活动对象。用户将操作作为参数或标志提供给 kubectl
命令。
这是入门或在集群中运行一次性任务的推荐方式。由于此技术直接操作活动对象,因此不提供以前配置的历史记录。
示例
通过创建 Deployment 对象来运行 nginx 容器的实例
kubectl create deployment nginx --image nginx
权衡
与对象配置相比的优点
- 命令表示为单个操作词。
- 命令只需要一个步骤即可更改集群。
与对象配置相比的缺点
- 命令不与更改审查过程集成。
- 命令不提供与更改相关的审计跟踪。
- 命令不提供记录来源,除了活动状态。
- 命令不提供创建新对象的模板。
命令式对象配置
在命令式对象配置中,kubectl 命令指定操作(创建、替换等)、可选标志和至少一个文件名。指定的文件必须包含 YAML 或 JSON 格式的对象的完整定义。
有关对象定义的更多详细信息,请参阅 API 参考。
警告
命令式replace
命令会用新提供的规范替换现有规范,丢弃配置文件中缺少的对象的所有更改。此方法不应与规范独立于配置文件更新的资源类型一起使用。例如,类型为 LoadBalancer
的 Service 的 externalIPs
字段由集群独立于配置进行更新。示例
创建配置文件中定义的对象
kubectl create -f nginx.yaml
删除两个配置文件中定义的对象
kubectl delete -f nginx.yaml -f redis.yaml
通过覆盖活动配置来更新配置文件中定义的对象
kubectl replace -f nginx.yaml
权衡
与命令式命令相比的优点
- 对象配置可以存储在 Git 等源代码控制系统中。
- 对象配置可以与诸如推送前审查更改和审计跟踪等过程集成。
- 对象配置为创建新对象提供了模板。
与命令式命令相比的缺点
- 对象配置需要对对象模式有基本的了解。
- 对象配置需要编写 YAML 文件的额外步骤。
与声明式对象配置相比的优点
- 命令式对象配置行为更简单且更易于理解。
- 从 Kubernetes 1.5 版本开始,命令式对象配置更加成熟。
与声明式对象配置相比的缺点
- 命令式对象配置最适用于文件,而不是目录。
- 对活动对象的更新必须反映在配置文件中,否则在下次替换期间将丢失。
声明式对象配置
当使用声明式对象配置时,用户操作本地存储的对象配置文件,但是用户不定义要对文件执行的操作。kubectl
会自动检测每个对象的创建、更新和删除操作。这使得可以在目录上工作,其中可能需要对不同对象执行不同的操作。
注意
声明式对象配置会保留其他编写者所做的更改,即使这些更改没有合并回对象配置文件。这可以通过使用patch
API 操作仅写入观察到的差异来实现,而不是使用 replace
API 操作来替换整个对象配置。示例
处理 configs
目录中的所有对象配置文件,并创建或修补活动对象。您可以先使用 diff
来查看将要进行的更改,然后应用
kubectl diff -f configs/
kubectl apply -f configs/
递归处理目录
kubectl diff -R -f configs/
kubectl apply -R -f configs/
权衡
与命令式对象配置相比的优点
- 直接对活动对象所做的更改将被保留,即使它们没有合并回配置文件中。
- 声明式对象配置更好地支持操作目录,并自动检测每个对象的操作类型(创建、修补、删除)。
与命令式对象配置相比的缺点
- 当结果出乎意料时,声明式对象配置更难调试和理解结果。
- 使用差异的部分更新会创建复杂的合并和修补操作。
下一步
上次修改时间为太平洋标准时间 2022 年 1 月 8 日下午 6:09:重新组织使用 Kubernetes 对象部分 (634c17f61c)