ArgoCD 部署运行手册代理

问题背景

在 GitOps 实践中，Argo CD 负责将 Git 仓库中的声明式配置同步到 Kubernetes 集群。但当部署链路变长、应用数量增多时，运维人员常面临几个具体痛点：

• 同步状态不透明：应用处于 OutOfSync 还是 Degraded，需要反复执行 argocd app get 才能确认，无法快速批量巡检。
• 回滚流程不统一：触发回滚时，有人手动 kubectl rollout undo，有人改 Git 分支再等待同步，操作路径不一致导致排障时间拉长。
• 健康检查滞后：应用可能在同步完成后仍然处于 Degraded 状态，但 Argo CD 默认的健康探针未必覆盖所有自定义资源，问题往往在流量到达后才暴露。

核心能力与工作流程

该技能围绕 argocd CLI 与 Argo CD API 构建了一条可重复的运行手册链路，核心步骤如下：

1. 状态采集：通过 argocd app list 与 argocd app get 拉取当前所有应用的同步与健康状态，输出结构化摘要，便于快速定位异常应用。
2. 同步自动化：对处于 OutOfSync 状态的应用执行 argocd app sync，支持按项目或标签批量触发，减少逐条操作的重复劳动。
3. 回滚操作：当健康检查未通过时，按运行手册执行 argocd app history 查询历史版本，再通过 argocd app rollback 回退到指定版本，替代临时性的 kubectl 操作。
4. 健康监控闭环：同步或回滚后再次调用 argocd app get 验证健康状态，确保应用回到 Healthy 后再结束本次操作。

对于使用 Kustomize 的项目，技能还支持通过 kustomize edit set image 或覆盖层（overlay）切换镜像版本，将版本变更纳入 Git 记录，保持 GitOps 流程完整。

适用边界与注意点

• 权限要求：执行同步、回滚和查询操作需要调用方持有 Argo CD 的 admin 或 edit 级 RBAC 权限，建议通过 ServiceAccount 的 token 调用 API，而非直接复用个人凭证。
• 环境差异：不同 Argo CD 实例的 API 版本和 CLI 版本可能存在差异，部分命令（如 argocd app rollback）在旧版本中行为不同，建议先确认版本兼容性。
• 健康探针覆盖：技能依赖 Argo CD 配置的 health check 规则，对于未配置探针的自定义资源，回滚后的状态判断可能不准确，需要额外接入应用层指标。
• 非 Argo CD 场景不适用：该技能假设部署链路以 Argo CD 为核心，若团队使用 Flux CD 或其他 GitOps 工具，需另行适配。