4. Deployment 资源模型：关键字段与版本漂移表现

Deployment 是 Kubernetes 中最常用的工作负载资源，也是多集群场景下版本漂移检测的核心对象。要准确识别漂移，必须先理解 Deployment 资源模型中与版本直接相关的关键字段，以及漂移在集群间的典型表现。

4.1 Deployment 关键字段解析

以下三个字段直接决定了 Deployment 的“版本”状态，也是 Argo CD 在比较期望状态与实际状态时的核心对比项：

4.2 字段详解与漂移场景

4.2.1 replicas —— 副本数漂移

副本数是最容易被手动修改的字段之一。运维人员可能通过 kubectl scale 临时调整某个集群的副本数以应对流量突发，但未同步回 Git 仓库，导致集群间副本数不一致。

4.2.2 image —— 镜像版本漂移

镜像字段是版本漂移的“重灾区”。当不同集群使用了不同的镜像 tag，或同一 tag 指向了不同的 digest，就会产生版本不一致。

# Git 仓库中定义的期望状态
spec:
  template:
    spec:
      containers:
      - name: app
        image: registry.example.com/myapp:v1.2.3

# 集群 A 实际运行状态（正确）
image: registry.example.com/myapp:v1.2.3

# 集群 B 实际运行状态（漂移）
image: registry.example.com/myapp:v1.2.3-hotfix  # tag 不同
# 或
image: registry.example.com/myapp@sha256:abc123...  # digest 不同

4.2.3 strategy —— 更新策略漂移

更新策略字段虽然不直接影响应用版本，但会影响发布行为的一致性。不同集群使用不同的 maxSurge 或 maxUnavailable 参数，可能导致滚动更新期间的服务可用性表现不一致。

# 期望策略（Git）
strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 25%
    maxUnavailable: 25%

# 集群 A 实际（正确）
maxSurge: 25%, maxUnavailable: 25%

# 集群 B 实际（漂移）
maxSurge: 50%, maxUnavailable: 0%  # 参数被修改

4.3 版本漂移的常见表现

在多集群环境中，Deployment 版本漂移通常表现为以下几种可观测现象：

1. 副本数不一致： 相同应用的 Pod 数量在不同集群间不同，导致流量承载能力不均。
2. 镜像版本不同： 不同集群运行着不同 tag 或 digest 的应用镜像，导致行为差异或功能缺失。
3. 更新策略参数不同： 滚动更新的速率、中断预算不一致，影响发布节奏和稳定性。
4. 标签/注解漂移： labels 或 annotations 被手动修改，导致 Service 选择器或监控告警失效。
5. 环境变量/配置差异： env 或 configMapRef 指向不同配置，导致应用行为不一致。

4.4 Deployment 版本漂移检测流程

下图展示了 Argo CD 检测 Deployment 版本漂移的核心流程，从 Git 期望状态到多集群实际状态的对比链路：

4.5 漂移检测的关键指标速查

下表总结了 Deployment 各字段的漂移检测方式与修复建议：

4.6 版本漂移的根因分析

理解漂移的常见根因，有助于在检测到漂移时快速定位问题：

• 手动运维操作： 运维人员直接使用 kubectl edit、kubectl scale、kubectl set image 修改了集群中的 Deployment。
• CI/CD 管道直接部署： 某些自动化管道绕过 GitOps 流程，直接向集群推送了不同版本的镜像。
• 集群间配置差异： 不同集群的 ConfigMap 或 Secret 内容不同，导致 Deployment 引用的环境变量或挂载配置不一致。
• 镜像仓库策略差异： 某些集群配置了镜像缓存或代理，拉取到的镜像 digest 与原始仓库不同。
• HPA 自动扩缩容： HPA 修改了 replicas 字段，但未同步回 Git，导致 Argo CD 检测到漂移。