Argo CD
GitOps 控制器：Application 声明「Git 的哪个目录 → 集群的哪个 ns」，持续对账。
一个 Application CR 把「仓库 + 路径 + revision」映射到「目标集群 + namespace」，控制器循环比对期望与实际状态，可配自动 sync、self-heal（有人手改就改回去）与 prune（Git 里删了就从集群删）。渲染层认 plain manifests、Kustomize、Helm 与 jsonnet；ApplicationSet 用生成器批量产出 Application。Web UI 里能直接看 diff、同步历史与每个资源的健康判定 —— 这是它相对 Flux 最直观的差别。CNCF 毕业项目。
上游活跃度
2026-08-23 抓取 · 数据来自 argoproj/argo-cd (github)star23,977
最近提交2026-08-23
最新版本v3.5.12026-08-12
数字由构建期抓取，非实时；star 数不同代码托管平台之间不可直接比较。
运行依赖
- 一个 Git 仓库（读权限即可；写回 Git 是别的组件的事）
- 纳管其他集群需要各集群的凭据（kubeconfig 或 ServiceAccount token）
上手前注意
- **谁来管 Argo CD 自己**：它的安装清单不进 Git 就成了整条链上唯一手工维护的部分（app-of-apps / 自管 Application 是常见解法）
- self-heal + prune 会主动撤销手工 kubectl 改动 —— 这是特性，但排障时临时改动会被「修复」掉，要先关 auto-sync
- 控制面放哪个集群决定故障域：它挂掉不影响已部署的工作负载，但那段时间**发布能力为零**
- Helm chart 由它渲染时，`helm list` 在集群里看不到 release —— 状态在 Application 里，不在 Helm 的 Secret 里