Argo CD 架构与调谐流程
Argo CD 控制面通常部署在 argocd Namespace。它保存声明与凭据的元数据，读取 Git 后在 Repo Server 渲染，再由 Application Controller 将期望状态与集群状态比较并执行同步。
1. 核心组件
| 组件 | 职责 | 生产关注点 |
|---|---|---|
argocd-server | Web UI、API、CLI gRPC/HTTP 入口 | TLS、SSO、入口访问控制 |
argocd-repo-server | 克隆仓库并渲染 Helm、Kustomize、YAML | 仓库凭据、网络、渲染超时与缓存 |
argocd-application-controller | 比较状态、计算同步计划、执行调谐 | 集群 RBAC、并发、队列、日志 |
argocd-redis | 缓存与协调数据 | HA 模式、持久化与版本兼容 |
argocd-dex-server | 内置身份代理，可选 | 生产通常接入外部 OIDC |
argocd-applicationset-controller | 按生成器生成 Application | 模板变更的批量影响 |
2. 调谐数据流
渲染与同步是两个阶段。Repo Server 有权读取 Git 并生成 Kubernetes 对象；真正写入集群的是 Application Controller 使用的集群凭据。因此仓库凭据和集群凭据应分开管理、分开授权。
3. 状态判断
- Synced：集群资源与 Git 渲染结果一致，不等同于应用可用。
- OutOfSync：存在新增、修改、删除或被忽略规则之外的差异。
- Healthy：Argo CD 根据资源类型的健康规则认为资源已就绪。
- Degraded / Progressing / Missing：资源失败、仍在滚动更新或未找到。
Synced + Healthy 才是常用的交付完成信号；生产流水线应同时等待同步完成和健康状态，而不是只等待 API 请求成功。
4. 组件边界与网络
Repo Server 需要访问 Git、Helm OCI 或 Chart 仓库；Application Controller 需要访问被托管集群的 Kubernetes API；用户和 CI 只应访问 argocd-server。NetworkPolicy 应按此流向放行，而不是为整个 Namespace 开放任意出站。