2. Kubernetes Deployment 基础：Deployment、ReplicaSet 与滚动更新机制
在集群升级场景中，Deployment 是最核心的工作负载抽象。它负责声明式地管理 Pod 副本，并驱动实际状态向期望状态收敛。理解 Deployment 的底层组件与更新机制，是校准版本漂移的前提。
2.1 Deployment 与 ReplicaSet 的关系
Deployment 并不直接管理 Pod，而是通过 ReplicaSet 实现副本控制。每个 Deployment 在每次更新时都会创建一个新的 ReplicaSet，并逐步调整新旧 ReplicaSet 的副本数，完成版本切换。
| 组件 | 职责 | 关键字段 |
|---|---|---|
| Deployment | 声明期望状态（镜像版本、副本数、更新策略） | spec.replicas、spec.template、spec.strategy |
| ReplicaSet | 确保指定数量的 Pod 副本运行，承载特定版本的 Pod Template | spec.replicas、spec.selector、spec.template |
| Pod | 实际运行容器的工作负载实例 | spec.containers[].image、status.phase |
关键认知：Deployment 的版本漂移校准，本质上是检测当前活跃 ReplicaSet 的 Pod Template 是否与集群期望版本一致。ReplicaSet 的
spec.template 一旦创建即不可变，因此它是版本锚定的最佳参照物。
2.2 滚动更新机制详解
滚动更新是 Deployment 默认的更新策略（strategy.type: RollingUpdate）。它通过控制新旧 ReplicaSet 的副本数变化，实现 Pod 的平滑替换，避免服务中断。
2.2.1 滚动更新核心参数
| 参数 | 默认值 | 含义 | 对版本漂移的影响 |
|---|---|---|---|
maxSurge |
25% | 更新期间允许超出期望副本数的最大 Pod 数（值或百分比） | 可能导致新旧版本 Pod 同时运行，增加漂移检测的复杂度 |
maxUnavailable |
25% | 更新期间允许不可用 Pod 的最大数量 | 控制更新速度，过快更新可能掩盖版本不一致问题 |
2.2.2 滚动更新流程（5 步）
- 创建新 ReplicaSet：Deployment 控制器根据新的
spec.template创建新 ReplicaSet，初始副本数为 0。 - 扩容新 ReplicaSet：按照
maxSurge限制，逐步增加新 ReplicaSet 的副本数。 - 缩容旧 ReplicaSet：按照
maxUnavailable限制，逐步减少旧 ReplicaSet 的副本数。 - 健康检查等待：新 Pod 通过 Readiness Probe 后，才继续下一批替换。
- 完成切换：旧 ReplicaSet 副本数归零，新 ReplicaSet 达到期望副本数，更新完成。
校准提示：在集群升级场景中，如果滚动更新被中断（如节点异常、控制器重启），可能出现新旧 ReplicaSet 均未达到期望副本数的“中间态”。此时 Pod 版本与 Deployment 期望版本不一致，即版本漂移。
2.3 Deployment 版本漂移的典型成因
| 成因 | 现象 | 影响范围 |
|---|---|---|
| 滚动更新被中断 | 新旧 ReplicaSet 均未完成副本数调整 | 部分 Pod 版本落后 |
| 手动修改 ReplicaSet | 直接编辑 RS 的 Pod Template（不推荐） | 单个 ReplicaSet 内版本混乱 |
| 集群升级导致控制器重启 | Deployment 控制器状态丢失，更新进度重置 | 全集群范围版本不一致 |
| HPA 与滚动更新并发 | 扩缩容与版本替换互相干扰 | 副本数与版本双重漂移 |
2.4 Deployment 版本锚定：ReplicaSet 的不可变 Template
ReplicaSet 的 spec.template 在创建后不可修改，这为版本校准提供了可靠锚点。校准测试的核心逻辑是：
# 获取 Deployment 当前期望的 Pod Template 哈希
kubectl get deployment <name> -o jsonpath='{.spec.template}' | sha256sum
# 获取当前活跃 ReplicaSet 的 Pod Template 哈希
kubectl get rs -l app=<label> -o jsonpath='{.items[*].spec.template}' | sha256sum
# 对比两个哈希值，不一致则存在版本漂移
注意：直接比较镜像标签（如
v1.0 vs v1.1）可能被标签覆盖或镜像仓库重定向误导。使用 Pod Template 的完整哈希比对，能更准确地检测版本漂移。
2.5 滚动更新状态机与版本漂移点
2.6 版本漂移校准测试的切入点
基于上述机制，校准测试应聚焦以下三个层面：
- ReplicaSet 层面：枚举 Deployment 关联的所有 ReplicaSet，比对它们的
spec.template哈希值，确认是否一致。 - Pod 层面：检查每个 Pod 所属的 ReplicaSet 是否与当前期望的 ReplicaSet 匹配，排除残留旧版本 Pod。
- 控制器层面：验证 Deployment 的
status.observedGeneration是否等于metadata.generation，确保控制器已完成最新更新。
实践建议：在集群升级前、升级中、升级后分别执行一次版本锚定检查。使用
kubectl rollout status deployment 确认更新完成，再通过 ReplicaSet 哈希比对做二次验证，可有效捕获版本漂移。