ArgoCD GitOps 同步控制器

这个技能解决什么问题

在 Kubernetes 上用 Argo CD 做 GitOps 时，一次发布往往不只是单个 Application：ApplicationSet 会按集群、命名空间生成一批资源，同步顺序、健康判定和回滚窗口都需要人为写进配置。结果是同步波次（sync waves）靠猜、健康检查（health checks）靠默认、渐进式推进靠手动暂停，发布节奏很难稳定复现。

它如何工作

这个技能围绕 Argo CD 的两类资源展开：Application 与 ApplicationSet。它不改变 Argo CD 本身的工作方式，而是通过 ArgoCD REST API 与 argocd CLI 两条路径来读写和驱动这些资源，把原本分散在 YAML 和命令行里的动作整理成可重复的流程。

核心能力：

• 资源管理：创建、更新、核对 Application 与 ApplicationSet，保持期望状态与集群实际状态一致。
• 同步波次编排：为相关资源设置 syncWave，控制先起依赖、后起前端，避免启动顺序竞态。
• 健康检查配置：调整 healthChecks，让控制器等待数据库、中间件真正可用后再继续推进。
• 渐进式部署：配置 Argo CD 的滚动推进参数，按批次扩大变更面。

典型流程：

1. 从 Git 仓库读取当前 ApplicationSet 与 Application 定义。
2. 调用 REST API 或 argocd CLI 查询现有对象与同步状态。
3. 为需要排序的资源补充 syncWave 与健康检查规则。
4. 触发同步并观察状态，确认无漂移后保留配置。

适用边界与注意点

• 它管理的是 Argo CD 侧的配置与同步动作，不替代外部的独立渐进式发布组件。
• 健康检查规则写得过严会拖慢发布，过松则可能放过未就绪的服务，需要按业务实际调整。
• 仓库里附带的 Couchbase 示例与 Argo CD 入门笔记偏向上手参考，生产使用前仍需结合自身集群验证。
• 上游文档以 Argo CD 官方 README 为准，版本差异可能导致字段名称变化。