本博客将详细的讲解Kubernetes如何管理控制对象
| 管理技术 | 作用于 | 建议的环境 | 支持的写者 | 学习难度 |
|---|---|---|---|---|
| 指令式命令 | 活跃对象 | 开发项目 | 1+ | 最低 |
| 指令式对象配置 | 单个文件 | 生产项目 | 1 | 中等 |
| 声明式对象配置 | 文件目录 | 生产项目 | 1+ | 最高 |
用户在集群中的活动对象上使用kubectl命令作为参数或标志，不提供以前配置的历史记录
通过创建Deployment对象来运行nginx容器的实例：
kubectl create deployment nginx --image nginx
与对象配置相比的优点：
命令用单个动词表示，更改集群仅需一步
与对象配置相比的缺点：
命令不与变更审查流程集成，命令不提供与更改关联的审核跟踪，除了实时内容外，命令不提供记录源，命令不提供用于创建新对象的模板（简单说就是，不会记录执行了什么命令，所以没法回溯跟踪，创建新对象没有模板，之后没法直接一键创建该对象）
kubectl命令指定操作（创建，替换等），可选标志和至少一个文件名，指定的文件包含YAML或JSON格式的对象的完整定义
创建配置文件中定义的对象：
kubectl create -f nginx.yaml
删除两个配置文件中定义的对象：
kubectl delete -f nginx.yaml -f redis.yaml
更新配置文件中定义的对象：
kubectl replace -f nginx.yaml
与指令式命令相比的优点：
对象配置可以存储在源控制系统中，对象配置可以与流程集成，例如在推送和审计之前检查更新，对象配置提供了用于创建新对象的模板
与指令式命令相比的缺点：
对象配置需要对对象架构有基本的了解，对象配置需要额外的步骤来编写YAML文件
与声明式对象配置相比的优点：
指令式对象配置行为更加简单易懂
与声明式对象配置相比的缺点：
指令式对象配置更适合文件，而非目录，对活动对象的更新必须反映在配置文件中，否则会在下一次替换时丢失
用户操作本地的对象配置文件，不用定义要对该文件执行的操作，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/
与指令式对象配置相比的优点：
对活动对象做的更改即使未合并到配置文件中，也会被保留下来，
声明性对象配置支持对目录进行操作并自动检测文件的操作类型（创建，修补，删除）
与指令式对象配置相比的缺点：
声明式对象配置难于调试，出现异常时结果难以理解，使用diff产生的部分更新会创建复杂的合并和补丁操作