Argo CD是面向 Kubernetes 的声明式 GitOps 持续交付工具，由 Intuit 于 2018 年开源，现为云原生计算基金会(CNCF)毕业项目 Argo 的子项目之一。它把 Git 仓库中的清单文件视为期望状态的唯一来源，持续比对集群实际状态并自动或手动同步，从而让应用部署可审计、可回滚[1]。
定义
Argo CD 是一款为 Kubernetes 设计的声明式、基于 GitOps 的持续交付工具。它把 Git 仓库里描述应用与环境的配置文件当作期望状态，由运行在集群内部的控制器把集群实际状态拉回到该期望状态，用户无需直接向集群推送变更[1][2]。
Argo CD 本身以 Kubernetes 控制器形式部署，是 Argo 项目下的四个子项目之一，其余三个为 Argo Workflows、Argo Events 和 Argo Rollouts。它的源码以 Apache 2.0 许可协议开放[3]。
原理
Argo CD 遵循 GitOps 模式，将 Git 仓库(以及 Helm 注册表、OCI 镜像等来源)作为定义期望应用状态的事实来源。用户创建 Application 资源时，需要指定存放清单的来源，以及目标集群与命名空间；控制器随后持续监测来源与集群实时状态，并在两者出现差异时自动同步[2]。
同步状态可以用一个简单的判定关系描述：当 $live\ state \ne desired\ state$ 时，应用被标记为 OutOfSync。控制器会展示差异，并提供自动或手动同步的机制，把实时状态改回目标状态[1]。
清单的生成方式包括 Kustomize、Helm、Jsonnet、纯 YAML/JSON 目录，或通过配置管理插件接入的自定义工具[1]。为提升性能，仓库服务器会缓存 Git 仓库副本和已生成的清单，应用控制器则按周期对应用做调谐，并把结果写入 Application 资源的状态字段。
flowchart LR
G[Git 仓库 / Helm / OCI] --> R[argocd-repo-server 生成清单]
R --> C[argocd-application-controller 比对状态]
C --> K[Kubernetes 集群]
C --> S[argocd-server 提供 API]
S --> U[Web UI / CLI]
S --> X[外部 CI 系统]
C --> N[通知控制器]
与传统的推送式流水线不同，Argo CD 采用以拉取为主的架构：由集群主动发起连接去获取配置，因此无需开放入站防火墙端口，也不必让 Git 仓库获得对私有集群的网络访问权限[4]。早期版本同时支持拉取与推送两种模型，Intuit 出于安全与合规考虑采用推送模型，由流水线调用 Argo CD 完成同步。
发展历程
Argo 项目最早源于 2017 年 8 月由 Applatix 公司发布的 Argo Workflows。Intuit 于 2018 年 1 月收购 Applatix，并在同年 1 月将 Argo CD 开源；其最初目的之一是让 Argo Workflows 更容易部署并与 Kubernetes 保持同步[5][6]。
Argo CD 于 2019 年 7 月发布 1.0 版本。2020 年 4 月，包含 Argo CD 在内的整个 Argo 项目进入云原生计算基金会孵化器，Red Hat 与 Intuit 等公司随后加入协作[5]。
2021 年 4 月，Argo CD 发布 2.0 版本，引入通知框架、跨集群管理用的 ApplicationSet、镜像更新器以及 Pod 视图等能力[7]。2022 年 12 月，Argo 项目在通过安全审计与治理评审后从 CNCF 毕业。2025 年 4 月，Argo CD 3.0 的预发布版本公布，重点改进授权机制、降低内存占用并提升大规模部署下的性能[8]。
应用
Argo CD 常被用在同一实例内跨多个集群、多个区域部署和管理应用，并通过 Web 界面或命令行查看部署状态、健康度与历史记录[2]。它提供 Application、ApplicationSet 与 AppProject 三类主要资源，分别用于定义单个部署、按模板批量生成多集群应用，以及对应用做逻辑分组和访问控制[2]。
在 Intuit 内部，Argo CD 被用作控制所有生产部署的 GitOps 工具，使开发者无需直接访问 Kubernetes 集群；该公司在其平台上运行着 200 多个 Kubernetes 集群和数千个应用[9]。欧洲核子研究中心(CERN)也曾借助它按需创建并释放数千个节点和图形处理器资源用于数据处理。
主流云厂商将其纳入托管服务：Amazon 在 EKS 中提供全托管的 Argo CD 能力，由云平台负责安装、扩缩与补丁，并通过其身份中心完成认证与授权[2]；Microsoft 则以集群扩展的形式在 AKS 与 Azure Arc 环境中提供 Argo CD[4]。Red Hat 将 Argo 集成进 OpenShift 生态，作为 OpenShift GitOps 的基础。
局限
Argo CD 关注从 Git 到 Kubernetes 的同步，本身不包含镜像漏洞扫描、合规检查等能力，安全扫描通常需要在持续集成阶段另行处理[10]。它还需要外部工具配合才能实现高级部署策略，例如金丝雀发布、SLO 触发的回滚和基于健康度的自动修复[10]。
随着应用数量增长，应用控制器与仓库服务器容易出现性能瓶颈，表现为同步变慢、界面响应迟滞、控制器内存占用升高。常见原因包括清单生成耗时、频繁查询 Kubernetes API 接口以及缓存使用不当；可通过调整状态处理进程数、操作进程数、分片配置和调谐间隔等方式缓解[11][12]。
由于清单生成采用的是模板渲染而非真正的安装或升级，Helm 的安装前与升级前钩子会在每次同步时重复执行，因此这些钩子需要具备可重复执行的性质，Helm 的 lookup 函数也无法使用[12]。
在开启自动修复与资源清理的情况下，启动较慢的工作负载可能在进入健康状态前就被重新同步甚至删除；此外，若两个应用或 ApplicationSet 管理同一 Kubernetes 资源，会出现资源归属冲突，资源可能长期无法达到稳定状态[2]。
参见
参考资料
- Overview¶ [引用日期2026-10-14]
- Continuous Deployment with Argo CD [引用日期2026-10-14]
- github.com/argoproj/argo-cd/v2 | Snyk [引用日期2026-10-14]
- Déploiements d’applications avec GitOps (Argo CD) [引用日期2026-10-14]
- The history of Argo [引用日期2026-10-14]
- redhat.com 上的网页 [引用日期2026-10-14]
- cncf.io 上的网页 [引用日期2026-10-14]
- cncf.io 上的网页 [引用日期2026-10-14]
- vmblog.com 上的网页 [引用日期2026-10-14]
- Common Challenges and Limitations of ArgoCD | Devtron [引用日期2026-10-14]
- Performance Considerations | Continuous Delivery | Harness [引用日期2026-10-14]
- The No-Nonsense Guide to ArgoCD [引用日期2026-10-14]