技能介绍

问题：GitOps 里的"假绿"状态

在 ArgoCD 管理的集群上，Application 显示 Healthy 且 SyncStatus 为 Synced，并不等于集群里的实际配置和 Git 仓库里的声明一致。一次绕过流水线的 kubectl apply、一次被手动改过的 ConfigMap、一个忘记回滚的临时 Patch，都会让运行时状态悄悄偏离 Git 这个唯一事实来源。

这类漂移最麻烦的地方在于：ArgoCD 默认的自愈行为会把 Live 状态拉回 Git，因此漂移往往在自愈完成后才被发现，甚至因为反复自愈造成抖动，让你拿不到一份稳定的"差异证据"。

这个技能做什么

核心思路很直接：不看 ArgoCD UI 的颜色，而是直接从数据面取证。

通过 ArgoCD REST API 与 grpc-gateway 读取 Application 的真实同步状态，拿到 Git 端声明的期望清单与集群端实际运行的清单。
将两者拉平对比，识别出字段级、顺序级以及被整体替换的资源差异。
借助 kubectl diff 生成修复剧本（remediation playbook），把"漂移在哪、应该怎么改回去"落成可执行的清单，而不是一句"去修一下"。

适用边界与注意点

该技能是检测与取证工具，不是 ArgoCD 的替代。它负责告诉你漂了什么、怎么修，不负责接管 Sync 流程本身。
生成的修复剧本需要自行审阅后再执行，尤其是涉及 StatefulSet 的 spec.volumeClaimTemplates 等不可字段级更新的资源。
依赖当前上下文中的 kubectl 与目标集群权限，Diff 的覆盖面取决于 RBAC 允许看到的范围；越权或未授权的资源不会被纳入对比。
对 CRD 数量大、资源众多的集群，逐资源拉取与 Diff 会有明显开销，建议在非高峰窗口运行。

本质上，它把你排查漂移时重复做的那几步——拉期望、拉实际、跑 diff、写修复脚本——固化成一条可重复的路径。