📚 课程目录第3章 Deployment基础回顾

3. Deployment 基础回顾：资源定义、ReplicaSet 与 Pod 的关系、版本管理机制

在深入跨集群版本漂移校准之前，必须牢固掌握 Deployment 的核心设计。Deployment 是 Kubernetes 中声明式管理无状态工作负载的顶层资源，它通过控制 ReplicaSet 来间接管理 Pod，并内置了版本记录与回滚机制。理解这三层关系是后续校准步骤的理论基础。

3.1 Deployment 资源定义核心字段

一个标准的 Deployment YAML 清单包含四个关键部分：apiVersion/kind/metadata（元数据）、spec.replicas（期望副本数）、spec.selector（标签选择器）、spec.template（Pod 模板）。其中 spec.selector 必须与 spec.template.metadata.labels 匹配，这是 ReplicaSet 接管 Pod 的契约。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
  labels:
    app: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
      tier: frontend
  template:
    metadata:
      labels:
        app: web
        tier: frontend
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        ports:
        - containerPort: 80

关键约束：spec.selector 一旦创建即不可变更（immutable）。如需修改标签选择器，必须删除并重建 Deployment。这是版本漂移校准中需要特别注意的边界条件。

3.2 Deployment、ReplicaSet 与 Pod 的三层关系

Deployment 并不直接管理 Pod。它通过 ReplicaSet 作为中间层实现版本控制与滚动更新。每次 Deployment 的 Pod 模板（template）发生变化时，Kubernetes 会创建一个新的 ReplicaSet，并逐步将旧 ReplicaSet 的副本数缩至 0，新 ReplicaSet 的副本数增至期望值。

下图展示了这三层资源的从属关系与版本迭代过程：

  核心结论：Deployment 的版本 = ReplicaSet 的版本。每个 ReplicaSet 对应一个 Pod 模板快照。版本漂移的本质是不同集群中 Deployment 所指向的“当前 ReplicaSet”不一致。

3.3 版本管理机制：修订历史与回滚

Deployment 的版本管理依赖 annotation 机制。每次 Pod 模板变更时，Kubernetes 会自动在 Deployment 和对应的 ReplicaSet 上添加 deployment.kubernetes.io/revision 注解，形成一个递增的修订版本号。

下表总结了版本管理的关键操作与对应命令：

操作	命令 / 行为	对版本号的影响
创建 Deployment	`kubectl create deployment`	生成 revision=1
更新镜像	`kubectl set image deployment`	生成 revision=2,3,4…
回滚到上一版本	`kubectl rollout undo deployment`	生成 revision=5（实际是复用 revision=3 的模板）
查看历史	`kubectl rollout history deployment`	列出所有 revision 及变更原因
回滚到指定版本	`kubectl rollout undo deployment --to-revision=2`	生成新 revision，Pod 模板与 revision=2 一致

版本漂移校准的核心正是利用 rollout history 和 rollout undo 机制，将不同集群的 Deployment 对齐到同一个期望的 revision 上。

3.4 版本漂移的典型场景

在跨集群环境中，版本漂移通常由以下原因引发：

手动热修复：运维人员直接在某个集群执行 kubectl set image 或 kubectl edit deployment，导致该集群的 revision 偏离基线。
CI/CD 管道不一致：不同集群的持续部署管道触发了不同时间点或不同分支的镜像构建。
回滚操作不同步：某个集群因故障执行了 rollout undo，而其他集群未同步执行。
GitOps 同步延迟：ArgoCD 或 Flux 在部分集群上同步失败，导致实际运行的 ReplicaSet 与 Git 仓库中的期望状态不一致。

校准前提：在执行版本漂移校准之前，必须先确认哪个 revision 是“期望版本”。通常以 Git 仓库中的 Deployment 清单为准，或由团队指定一个基准集群的当前 revision 作为校准目标。

下图展示了版本漂移的典型状态——两个集群的 Deployment 指向了不同的 ReplicaSet：