技能介绍

问题背景：GitOps 漂移为何难以发现

GitOps 希望 Kubernetes 集群状态由 Git 仓库中的清单声明式驱动，但 ArgoCD 的同步状态只反映应用是否收敛到期望状态，并不直接暴露配置漂移。当运维人员通过 kubectl 直接修改资源、绕过 Git 提交，或 Git 仓库更新后同步失败时，Git 清单与集群实际运行状态会逐渐偏离。这种漂移往往在故障发生后才被发现，手工执行 kubectl get 逐个核对资源既耗时又容易遗漏，缺少一个面向工程师的自动化检测入口。

工作原理与核心步骤

该技能通过两个 API 层协作完成检测：

拉取 ArgoCD 应用状态：访问 GET /api/v1/applications 端点，获取所有应用的同步状态（SyncStatus）与健康状态（HealthStatus），快速识别同步失败、OutOfSync 或异常的应用。
读取集群实时状态：通过 Kubernetes API 获取目标应用关联的实时资源对象，包括 metadata.resourceVersion、spec 等字段，还原集群当前实际配置。
Git 清单与集群比对：将 Git 仓库中的期望清单（如 Deployment、Service、ConfigMap）与集群实际状态进行字段级 diff，定位被修改或遗漏的配置项。
输出结构化偏差报告：汇总偏差涉及的资源名称、命名空间、字段路径及可能原因，方便工程师直接定位修复。

适用边界与注意事项

该工具不替代 ArgoCD 自身的同步逻辑，而是作为外部巡检手段暴露已发生的漂移。使用时需注意：

权限要求：需要 ArgoCD API 的读权限以及 Kubernetes 的 get/list 权限，否则无法读取应用和资源对象。
覆盖范围：主要面向标准声明式资源，对自定义资源（CRD）的深度比对需额外配置 schema。
Git 访问：若需读取上游 Git 清单，需配置正确的仓库地址与凭证。
请求频率：高频轮询 /api/v1/applications 需控制请求速率，避免对 ArgoCD 和 Kubernetes API Server 造成额外压力。