2. Kubernetes Deployment 基础：Deployment 工作原理、ReplicaSet 与 Pod 的关系、版本管理机制

2.1 Deployment 工作原理

Deployment 是 Kubernetes 中最常用的工作负载 API 对象，它提供了声明式的 Pod 和 ReplicaSet 更新能力。其核心设计理念是“通过控制器模式驱动实际状态向期望状态收敛”。

Deployment 控制器的工作流程可概括为以下步骤：

1. 监听与比对：控制器通过 Informer 机制监听 Deployment、ReplicaSet、Pod 的资源变化，持续比对 spec.replicas 与当前集群中对应 Pod 的数量。
2. 版本协调：当 Deployment 的 spec.template 发生变化（如镜像版本更新）时，控制器会创建新的 ReplicaSet，并逐步缩容旧的 ReplicaSet。
3. 滚动更新：按照 spec.strategy.rollingUpdate 中定义的 maxSurge 和 maxUnavailable 参数，控制 Pod 的替换速率。
4. 状态持久化：将当前的版本号、可用副本数、更新进度等状态写入 status 字段，供外部监控或调度系统读取。

2.2 ReplicaSet 与 Pod 的关系

ReplicaSet 是 Deployment 与 Pod 之间的中间层，其核心职责是确保指定数量的 Pod 副本始终运行。理解三者之间的关系是掌握版本管理的基础。

ReplicaSet 通过 spec.selector.matchLabels 来识别其管理的 Pod。每个 Pod 在创建时会被打上对应的标签，并设置 ownerReferences 指向所属的 ReplicaSet。这种基于标签的松耦合关系，使得 ReplicaSet 可以灵活地接管或释放 Pod。

2.3 版本管理机制

Kubernetes Deployment 的版本管理机制基于 ReplicaSet 的历史记录。每次 Deployment 的 spec.template 发生变化时，控制器都会创建一个新的 ReplicaSet，并将旧的 ReplicaSet 保留在历史记录中。

2.3.1 版本号与修订历史

Deployment 使用 metadata.generation 和 status.observedGeneration 来跟踪期望状态的变更次数。每次 spec.template 的变更都会递增 generation。同时，spec.revisionHistoryLimit 控制保留的历史 ReplicaSet 数量（默认 10）。

# 查看 Deployment 的修订历史
kubectl rollout history deployment/my-app

# 输出示例
REVISION  CHANGE-CAUSE
1         <none>
2         <none>
3         kubectl set image deployment/my-app my-app=nginx:1.21

2.3.2 回滚机制

当需要回滚到某个历史版本时，Deployment 控制器会执行以下操作：

• 查找目标 ReplicaSet：根据指定的 revision 找到对应的 ReplicaSet。
• 复制 Pod 模板：将目标 ReplicaSet 的 spec.template 复制到 Deployment 的 spec.template 中。
• 触发更新：由于 spec.template 发生变化，控制器会创建新的 ReplicaSet（其 Pod 模板与目标版本一致），并逐步缩容当前活跃的 ReplicaSet。

2.3.3 版本管理关键参数

2.3.4 版本漂移的典型场景

在单集群中，版本漂移通常由以下原因引起：

• 手动修改 Pod 标签：直接修改 Pod 的标签，使其脱离 ReplicaSet 的管理范围，导致 ReplicaSet 创建新的 Pod 来补足副本数。
• 直接修改 ReplicaSet：绕过 Deployment 直接修改 ReplicaSet 的 Pod 模板，导致与 Deployment 的期望状态不一致。
• 并发更新冲突：多个用户或 CI/CD 系统同时更新同一个 Deployment，导致控制器交替创建不同的 ReplicaSet。