GitOps 漂移检测：集群里改了配置，Git 还以为一切正常

GitOps 的理念是 Git 作为事实来源。但生产里总会有人临时改集群配置：手动 scale、临时 patch、紧急改 ConfigMap。如果没有漂移检测，Git 里看起来一切正常，集群里已经变了。

GitOps 不是只会同步，也要能发现现实偏离声明。

一、什么是配置漂移

flowchart TD A[Git Desired State] --> C[Drift Detection] B[Cluster Actual State] --> C C --> D[Diff] D --> E[Sync Or Alert]

漂移就是实际状态和声明状态不一致。它可能来自人工操作，也可能来自控制器动态修改。

二、漂移要分类

yaml 复制代码

drift_types:
  expected:
    - status
    - managed_fields
  suspicious:
    - image_tag_changed
    - replicas_changed
    - env_changed
    - resource_limit_removed

不是所有 diff 都要告警。status 字段变化正常，镜像和环境变量变化就要小心。

三、自动修复要谨慎

有些 GitOps 工具可以自动 sync，把集群拉回 Git 状态。但紧急修复期间，自动覆盖可能制造二次事故。

text 复制代码

auto_sync_policy:
  dev: enabled
  staging: enabled
  prod: manual_approval

生产环境是否自动修复，要结合团队值班和变更流程决定。

四、漂移也要进审计

发现漂移时，要记录资源、字段、发现时间、处理人和处理结果。

json 复制代码

{
  "resource": "deployment/api",
  "field": "spec.replicas",
  "desired": 4,
  "actual": 8
}

这类记录能帮助复盘：为什么有人绕过 Git 改集群？

漂移检测也要和紧急变更流程配合。生产事故中，值班人员可能必须临时 patch 集群。此时应该有 break-glass 流程：记录原因、设置过期时间、事后补 PR。

yaml 复制代码

break_glass:
  reason_required: true
  expires_in: "2h"
  follow_up_pr_required: true

这样既保留紧急处理能力，又不会让临时改动长期漂在集群里。

漂移报告最好按风险排序。镜像、环境变量、资源限制、权限相关字段优先级高；副本数变化次之；status 类字段直接忽略。否则值班人员会被大量无意义 diff 淹没。

五、总结

GitOps 漂移检测要比较 Git 声明状态和集群实际状态，区分正常差异和危险差异，并谨慎处理自动修复。

Git 是事实来源，但集群才是正在运行的现实。两边不一致时，系统必须知道。

GitOps 的成熟度，不在于永远没人手改，而在于手改发生后能被发现、解释、收敛回 Git。

漂移检测还可以作为发布前检查。新版本发布前，先确认目标命名空间没有未解释漂移。否则你以为发布覆盖的是 Git 状态，实际覆盖的是一堆临时改动。

text 复制代码

pre_deploy_check:
  drift_detected: false
  break_glass_expired: false
  pending_manual_patch: false

如果存在漂移，就先决定：把集群状态回写 Git，还是把集群恢复到 Git。不要带着不明差异继续发布。