技能介绍

它解决什么问题

ArgoCD 把 Kubernetes 的状态收敛到声明式清单里，但当 Application 出现 OutOfSync 时，问题往往不是「没人知道」，而是「知道得太晚」。典型场景：CI 合并后 Application 与目标集群漂移了好几分钟，直到有人打开 ArgoCD UI 才注意到；多个 Application 按 sync wave 分批启动，某一批失败后后续波次连锁卡住；有人手动 kubectl apply，GitOps 边界被打破，而 diff 从来没有人看过。

这个技能把这类信号从「人工巡检 UI」变成可脚本化的监控动作：通过 ArgoCD REST API 和 argocd CLI 采集 Application 的同步状态，而不是等人打开网页。

核心能力

OutOfSync 检测：读取 Application 的 sync status，找出哪些应用正处于 OutOfSync，即清单与集群实际状态不一致。
同步波次进度跟踪：按 sync wave 观察各 Application 的同步推进情况，定位「卡在哪一波」。
失败告警：同步操作失败时触发警报，把失败从静默状态变成显式信号。
资源级 Diff 分析：对目标应用调用 argocd app diff，拿到字段级变更细节，而不是只有「OutOfSync」这个布尔结果。

关键步骤

通过 REST API 或 argocd app list 获取 Application 清单与同步状态。
过滤出 OutOfSync 或 Degraded 条目，进入下一步排查。
用 argocd app diff <app> 对比 Git 清单与集群实际资源。
结合 sync wave 判断失败波次及其对后续 Application 的影响。
汇总为告警结果，交给通知通道或值班流程。

适用边界与注意点

它只负责观测与诊断，不会自动执行 argocd app sync 或回滚，修复动作仍需人工或 CI 承担。
argocd app diff 的输出依赖 CLI 与 API 对目标 Application 的读取权限，凭据需要预先配置好。
sync wave 的顺序由 Application 清单中的 syncWaveIndex / syncWave 字段决定，若项目没有规范标注波次，跟踪效果会打折扣。
漂移资源不在 Git 清单中时，diff 结果可能不完整，这种情况需要结合 kubectl 等工具交叉确认。
高频轮询 REST API 会给 ArgoCD API server 增加压力，建议设置合理的检查间隔而不是持续轮询。