Kubernetes v1.29 第五章：Pod控制器-Deployment 笔记
一、核心概念：声明式定义 vs 命令式定义
声明式与命令式是两种相对的资源管理思路，核心差异如下：
- 声明式定义：对最终结果的表述，仅表达意图而不指定实现过程，由系统自动调整资源状态到目标状态，灵活性更高。例如表达“应该有一个包含3个Pod的ReplicaSet”，系统会自动完成创建、异常修复等过程，过程中可根据实际情况灵活适配。
- 命令式定义：主动直接下达具体执行指令，要求系统严格按照步骤执行，不需要自主判断，逻辑简单但灵活性低。例如直接下达“创建一个包含3个Pod的ReplicaSet”的指令，系统仅执行当前步骤，不会自动适配后续变化。
辅助理解示例：期望孩子成为小提琴家，命令式是给孩子制定每天精确到时间节点的练习计划，必须严格按步骤执行；声明式是和孩子约定“以成为小提琴家为目标，自主安排练习”，孩子可根据当天身体情况调整计划，最终达成目标。
- 两者并非完全独立：声明式可降级为命令式，命令式也可视为声明式在特定场景下的简化表达。
- 优劣对比：声明式更适配大规模集群运维，灵活性高但逻辑相对复杂；命令式逻辑简单直接，但无法适配中间异常，容易产生服务真空期。
二、声明式/命令式对应的kubectl命令及差异
Kubernetes中典型的命令式命令是kubectl replace，典型的声明式命令是kubectl apply，核心差异如下：
- 替换逻辑差异：
replace：新配置完全覆盖现有资源的所有配置，无论新配置是否指定了全部字段，都会直接替换整个资源对象。apply：仅将新配置中发生变更的部分更新到现有资源，未指定/未变更的字段保留原有配置，不会全量覆盖。
- 字段级更新差异：
replace：完全替换当前资源的所有字段和属性，无论新配置是否包含这些字段。apply：仅更新新配置中明确指定的、与现有状态不同的字段，未指定的字段不做修改。
- 部分更新支持差异：
replace：不支持部分更新，必须提供完整的资源配置文件，否则会丢失未配置的字段（如默认副本数）。apply：支持部分更新，仅需在配置文件中声明需要变更的字段即可，无需提供完整配置。
- 多配置协同差异：
replace：不考虑其他资源配置，直接按当前文件覆盖目标资源。apply：支持通过--prune、--selector等参数读取多个配置文件，仅更新变更部分，保留未变更/未指定的配置。
三、实验演示：Deployment部署与命令实操
3.1 实验准备
首先清理集群中之前实验遗留的Pod、Service等资源，避免资源冲突导致实验结果不可靠。
3.2 Deployment资源清单核心字段解析
首次接触Deployment的资源定义，关键字段说明：
apiVersion: apps/v1：Kubernetes 1.16+版本统一使用该接口组，1.16之前使用extensions/v1（已废弃，旧版本资源清单需升级字段才能正常使用）。kind: Deployment：资源类型为Deployment控制器。metadata：定义Deployment的元数据，包括名称、标签（注意是Deployment控制器自身的标签，和Pod的标签区分）。spec.selector：定义Deployment匹配Pod的规则，必须和Pod模板中的标签匹配，支持标签选择器、字段选择器两种匹配方式（区别于早期ReplicationController仅支持标签选择器，功能更完善）。spec.template：定义Pod的模板，包括Pod的元数据（标签必须和selector匹配）、容器规格（镜像、端口等）。replicas：定义期望的Pod副本数，不填写时默认值为1。
3.3 apply命令（声明式）实操
- 将Deployment资源清单粘贴到编辑器中，执行
kubectl apply -f deployment.yaml部署资源。 - 验证：执行
kubectl get pods可看到对应Pod已正常运行。 - 调整副本数：执行
kubectl scale deployment/miv-deployment --replicas=10，验证Pod数量变为10，原有Pod不受影响。 - 升级镜像版本：修改资源清单中容器镜像版本从
1.0改为2.0，再次执行kubectl apply -f deployment.yaml，验证Pod完成滚动更新，版本变为2.0，副本数仍为10。
3.4 replace命令（命令式）实操
- 修改资源清单中镜像版本从
2.0改为3.0，执行kubectl replace -f deployment.yaml。 - 验证：执行
kubectl get pods可看到副本数变为1（因为资源清单中未填写replicas字段，replace直接覆盖了原有的副本数配置，变为默认值1），镜像版本已更新为3.0。 - 结论：replace会直接按当前文件全量覆盖集群中的资源对象，未在文件中声明的字段会被重置为默认值。
3.5 补充命令：kubectl diff
- 作用：对比当前本地资源清单和集群中已运行的同名资源对象的差异，提前预览变更内容，避免误操作。
- 用法：
kubectl diff -f deployment.yaml，输出内容类似vim的diff结果，标记出变更的字段。 - 适用场景：生产环境更新资源前，可通过diff确认变更内容是否符合预期，避免误改配置。
四、Deployment工作原理与滚动更新
4.1 层级管控逻辑
Deployment不直接管理Pod，而是通过两级管控实现管理：
- Deployment控制器先创建/管理ReplicaSet（RS）资源对象，在Deployment中定义副本数、镜像版本等期望状态。
- ReplicaSet再负责管理Pod的创建、销毁、扩缩容，最终实现Pod的生命周期管理。
层级关系：
Deployment -> ReplicaSet -> Pod
4.2 滚动更新原理
当需要升级应用版本时，Deployment不会直接杀掉所有旧Pod重建，而是通过逐步调整新旧ReplicaSet的副本数实现滚动更新，保证服务不中断：
- 创建新版本的ReplicaSet，初始副本数为0。
- 逐步提升新ReplicaSet的副本数，同时降低旧ReplicaSet的副本数，例如：新RS副本数从0升到2，旧RS从3降到2；新RS升到3，旧RS降到1；新RS升到3，旧RS降到0。
- 整个过程始终有旧版本的Pod在提供服务，不会出现服务真空期，用户访问不受影响。
4.3 滚动更新的优势
- 服务零中断：更新过程中始终有可用实例提供服务，避免批量重建导致的访问失败。
- 灰度发布支持：可配合配置调整新版本Pod的权重，实现灰度放量，验证新版本稳定性后再全量上线。
- 自动回滚：若新版本出现异常，Deployment可自动回滚到旧版本，降低故障影响。
AI 总结
本部分内容围绕Kubernetes Deployment控制器展开，首先明确了声明式定义与命令式定义的核心差异、适用场景，通过对比kubectl apply和kubectl replace的命令特性，结合实操演示验证了两类命令的行为区别；同时讲解了Deployment「不直接管理Pod、通过ReplicaSet间接管控」的层级原理，以及滚动更新的实现逻辑和优势，帮助理解Kubernetes声明式API的设计理念与生产环境中的应用逻辑。