argoproj/argo-cd

GitHub Trending (daily) 工具
gitops kubernetes continuous-delivery declarative devops

摘要

Argo CD 是一个用于 Kubernetes 的声明式 GitOps 持续交付工具，能够实现应用程序的自动化部署和生命周期管理。

面向 Kubernetes 的声明式持续部署
查看原文
查看缓存全文

缓存时间: 2026/07/09 07:51

argoproj/argo-cd

来源：https://github.com/argoproj/argo-cd

发布版本： 最新版本 (https://github.com/argoproj/argo-cd/releases/latest) Artifact HUB (https://artifacthub.io/packages/helm/argo/argo-cd) SLSA 3 (https://slsa.dev)

代码质量： 集成测试 (https://github.com/argoproj/argo-cd/actions?query=workflow%3A%22Integration+tests%22) codecov (https://codecov.io/gh/argoproj/argo-cd) CII 最佳实践 (https://bestpractices.coreinfrastructure.org/projects/4486) OpenSSF 评分卡 (https://scorecard.dev/viewer/?uri=github.com/argoproj/argo-cd)

社交渠道： Twitter 关注 (https://twitter.com/argoproj) Slack (https://argoproj.github.io/community/join-slack) LinkedIn (https://www.linkedin.com/company/argoproj/) Bluesky (https://bsky.app/profile/argoproj.bsky.social)

Argo CD —— Kubernetes 声明式持续交付

什么是 Argo CD？

Argo CD 是一款面向 Kubernetes 的声明式 GitOps 持续交付工具。

Argo CD 界面

Argo CD 演示 (https://youtu.be/0WAm0y2vLIo)

为什么选择 Argo CD？

  1. 应用定义、配置和环境应当是声明式且版本控制的。
  2. 应用部署和生命周期管理应当自动化、可审计且易于理解。

谁在使用 Argo CD？

官方 Argo CD 用户列表

文档

要了解更多关于 Argo CD 的信息，请访问完整文档 (https://argo-cd.readthedocs.io/)。 在线演示请访问 https://cd.apps.argoproj.io/。

社区

贡献、讨论与支持

您可以通过以下渠道联系 Argo CD 社区和开发者：

  • 问答：GitHub Discussions (https://github.com/argoproj/argo-cd/discussions)
  • 聊天：#argo-cd Slack 频道 (https://argoproj.github.io/community/join-slack)
  • 贡献者办公时间：每周四 (https://calendar.google.com/calendar/u/0/[email protected]) | 议程 (https://docs.google.com/document/d/1xkoFkVviB70YBzSEa4bDnu-rUZ1sIFtwKKG1Uw8XsY8)
  • 用户社区会议：每月第一个星期三 (https://calendar.google.com/calendar/u/0/[email protected]) | 议程 (https://docs.google.com/document/d/1ttgw98MO45Dq7ZUHpIiOIEfbyeitKHNfMjbY5dLLMKQ)

参与 Argo CD 项目需遵守 CNCF 行为准则 (https://github.com/cncf/foundation/blob/master/code-of-conduct.md)

博客与演讲

  1. Awesome-Argo：关于 Argo 的优秀项目与资源精选列表 (https://github.com/terrytangyuan/awesome-argo)
  2. 揭秘 Argo CD 在企业级持续交付中的秘密配方 (https://akuity.io/blog/secret-ingredients-of-continuous-delivery-at-enterprise-scale-with-argocd/)
  3. 使用 ArgoCD Image Updater 实现无管线的 GitOps (https://youtu.be/avPUQin9kzU)
  4. 结合 Argo CD (GitOps)、Crossplane (控制平面) 和 KubeVela (OAM) (https://youtu.be/eEcgn_gU3SM)
  5. 如何将 GitOps 应用于一切——结合 Argo CD 和 Crossplane (https://youtu.be/yrj4lmScKHQ)
  6. Couchbase——如何在 Kubernetes 中使用 Argo CD 运行数据库集群 (https://youtu.be/nkPoPaVzExY)
  7. 万物自动化——如何结合 Argo Events、Workflows & Pipelines、CD 和 Rollouts (https://youtu.be/XNXJtxkUKeY)
  8. 基于 Pull Request 的环境：使用 Argo CD 在预览环境中应用 GitOps 原则 (https://youtu.be/cpAaI8p4R60)
  9. Argo CD：应用 GitOps 原则管理 Kubernetes 生产环境 (https://youtu.be/vpWQeoaiRM4)
  10. 基于 Pull Request 创建临时预览环境：Argo CD 与 Codefresh (https://codefresh.io/continuous-deployment/creating-temporary-preview-environments-based-pull-requests-argo-cd-codefresh/)
  11. 教程：成为 GitOps 忍者所需的一切 (https://www.youtube.com/watch?v=r50tRQjisxw) —— 90 分钟 GitOps 和 Argo CD 教程。
  12. Argo CD、Spinnaker、Jenkins X 和 Tekton 对比 (https://www.inovex.de/blog/spinnaker-vs-argo-cd-vs-tekton-vs-jenkins-x/)
  13. 使用 IBM Multicloud Manager 3.1.2 通过 GitOps 简化并自动化部署 (https://www.ibm.com/cloud/blog/simplify-and-automate-deployments-using-gitops-with-ibm-multicloud-manager-3-1-2)
  14. 使用 Argo CD 实现 Kubeflow 的 GitOps (https://v0-6.kubeflow.org/docs/use-cases/gitops-for-kubeflow/)
  15. 基于 Kubernetes 的 GitOps 工具集：CircleCI 与 Argo CD (https://www.digitalocean.com/community/tutorials/webinar-series-gitops-tool-sets-on-kubernetes-with-circleci-and-argo-cd)
  16. 借助 K8s 和 Argo CD 实现光速 CI/CD (https://www.youtube.com/watch?v=OdzH82VpMwI&feature=youtu.be)
  17. 机器学习即代码 (https://www.youtube.com/watch?v=VXrGp5er1ZE&t=0s&index=135&list=PLj6h78yzYM2PZf9eA7bhWnIh_mK1vyOfU)。其中描述了 Kubeflow 如何使用 Argo CD 为机器学习实现 GitOps。
  18. Argo CD —— Kubernetes 的 GitOps 持续交付 (https://www.youtube.com/watch?v=aWDIQMbp1cc&feature=youtu.be&t=1m4s)
  19. Argo CD 入门：Kubernetes DevOps CI/CD (https://www.youtube.com/watch?v=2WSJF7d8dUg&feature=youtu.be)
  20. GitOps 部署与 Kubernetes——使用 Argo CD (https://medium.com/riskified-technology/gitops-deployment-and-kubernetes-f1ab289efa4b)
  21. 三步部署 Argo CD 并配置 Ingress 和 TLS：无需折腾 YAML (https://itnext.io/deploy-argo-cd-with-ingress-and-tls-in-three-steps-no-yaml-yak-shaving-required-bc536d401491)
  22. 使用 Argo 和 Codefresh 实现 GitOps 持续交付 (https://codefresh.io/events/cncf-member-webinar-gitops-continuous-delivery-argo-codefresh/)
  23. 使用 Argo CD 和 Renovate 保持最新 (https://mjpitz.com/blog/2020/12/03/renovate-your-gitops/)
  24. 使用 Helm 设置 Argo CD (https://www.arthurkoziel.com/setting-up-argocd-with-helm/)
  25. 使用 Argo CD 应用 GitOps (https://thenewstack.io/applied-gitops-with-argocd/)
  26. 使用 Argo CD 通过 GitOps 解决配置漂移 (https://www.cncf.io/blog/2020/12/17/solving-configuration-drift-using-gitops-with-argo-cd/)
  27. 跨环境的去中心化 GitOps (https://blogs.sap.com/2021/05/06/decentralized-gitops-over-environments/)
  28. ArgoCD GitOps 部署入门 (https://youtu.be/AvLuplh1skA)
  29. 使用 Argo CD 和 Datree 实现稳定的 Kubernetes CI/CD 部署 (https://youtu.be/17894DTru2Y)
  30. 如何使用 ApplicationSet 自动创建 Argo CD 应用？“GitOps 自动化” (https://amralaayassen.medium.com/how-to-create-argocd-applications-automatically-using-applicationset-automation-of-the-gitops-59455eaf4f72)
  31. 服务网格下的渐进式交付——Argo Rollouts 与 Istio (https://www.cncf.io/blog/2022/12/16/progressive-delivery-with-service-mesh-argo-rollouts-with-istio/)

相似文章

# 为什么 GitOps 这么好？ > "基础设施即代码"一词由 Kief Morris 在 2013 年创造。它指的是通过机器可读的定义文件来管理和配置基础设施（如服务器、网络等），而不是通过手动配置流程。 ## 什么是 GitOps？ GitOps 是一种使用 Git 作为唯一事实来源（Single Source of Truth）来管理基础设施和应用程序部署的实践。其核心理念是： - 所有配置和状态都存储在 Git 仓库中 - 任何变更都通过提交到 Git 仓库来实现 - 通过自动化工具将 Git 仓库中的状态同步到实际运行环境 GitOps 由 Weaveworks 于 2017 年提出。 ## 为什么 GitOps 这么好？ ### 1. 版本控制与审计追踪 Git 本身就是为版本控制而生。每一次变更都有记录： - **谁** 做了更改 - **什么时候** 做的 - **为什么** 做这个更改（通过 commit message） - 改了 **什么**（通过 diff） ### 2. 审查流程 通过 Pull Request（PR）或 Merge Request（MR），团队可以在变更生效之前进行审查和讨论，大大降低了引入错误的风险。 ### 3. 快速回滚 因为所有状态都记录在 Git 中，回滚操作非常简单： ```bash git revert <commit-hash> ``` ### 4. 一致性与可重复性 GitOps 保证了环境的一致性。无论在哪个环境中部署，使用的都是同一份配置文件，避免了"在我机器上能跑"的问题。 ### 5. 开发者体验友好 开发者不需要学习复杂的基础设施管理工具，只需要熟悉 Git 操作即可参与基础设施管理。 ### 6. 自愈能力 许多 GitOps 工具（如 ArgoCD、Flux）会持续监控实际状态与 Git 中声明的状态是否一致，如果有人手动修改了环境，工具会自动将其恢复到 Git 中声明的状态。 ## 核心原则 GitOps 基于以下几个核心原则： 1. **声明式配置** — 使用 YAML/JSON 等声明式语法描述系统的期望状态 2. **版本控制与不可变性** — 所有变更通过 Git 提交完成，不可直接修改运行环境 3. **自动化应用** — 自动检测 Git 仓库中的变更并应用到基础设施中 4. **持续协调** — 自动检测并修复运行环境与声明状态之间的偏差 ## 常用工具 - **ArgoCD** — 一个声明式的 GitOps 持续交付工具，专为 Kubernetes 设计 - **Flux** — 一个轻量级的 GitOps 工具，同样面向 Kubernetes - **Terraform** — 基础设施即代码工具，可与 GitOps 流程结合使用 ## 总结 GitOps 之所以优秀，是因为它将软件工程的最佳实践（版本控制、代码审查、自动化）引入了基础设施管理领域，使得运维变得更加可靠、透明和高效。

Lobsters Hottest

# 为什么 GitOps 如此有效？ 在过去的几年里，"GitOps" 这个词已经从边缘概念变成了云原生领域的主流实践。它并不是一个全新的产品，也不是某家公司注册的商标——它是一种工作方式：**把一切都当作代码来运行（everything as code）**，用声明式、可版本化、持续被调和（reconciled）的状态来描述你的整个基础设施。 一旦你真正理解了这三点，就会发现 GitOps 之所以有效，并不是因为它"时髦"，而是因为它把运维中最脆弱的环节——**人类的记性和手工操作**——从关键路径上移除了。 ## 一句话定义 GitOps 的核心思想很简单： > 以 Git 仓库作为唯一可信来源（Single Source of Truth），用声明式的方式描述系统的期望状态，然后由自动化工具持续将实际状态调和（reconcile）到期望状态。 拆开来看，它包含三个关键词： - **声明式（Declarative）**：你描述"系统应该是什么样"，而不是"要执行哪些步骤"。 - **版本化（Versioned）**：每一次变更都是一次 commit，天然拥有历史、作者、评审记录和回滚能力。 - **持续调和（Continuously Reconciled）**：有一个控制器 7×24 小时地对比实际状态与期望状态，一旦出现偏差就自动修正。 ## 为什么是"声明式"，而不是"命令式"？ 在 GitOps 出现之前，大多数部署脚本都是命令式的： ```bash kubectl apply -f deployment.yaml kubectl scale --replicas=3 api-server kubectl set image deployment/api-server api=registry/api:1.4.2 ``` 这是一个"步骤列表"。问题在于：**步骤列表是有序的、有状态的、且不可重放的。** 执行到一半失败了怎么办？某一步被漏掉了怎么办？两台机器上同时执行会怎样？更糟糕的是，几天之后没有人能确定集群到底处于什么状态——脚本跑过，但没人敢保证它跑对了。 声明式则完全不同。你只需要维护一份 YAML（或其他格式）的清单，描述： ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: api-server spec: replicas: 3 selector: matchLabels: app: api-server template: metadata: labels: app: api-server spec: containers: - name: api-server image: registry/api:1.4.2 ``` 你不去告诉系统"怎么做"，而是告诉它"要什么"。至于怎么达到这个状态，交给控制器。这种模式的好处是**幂等**：无论你执行多少次，结果都一样；无论从哪个时间点重新执行，结果也一样。 ## 为什么是"版本化"？ Git 是 GitOps 的名字来源，绝非偶然。把期望状态放进 Git，意味着你免费获得了一整套工程化能力： - **审计追踪**：谁在什么时候改了什么？为什么改？一条 `git log` 就能回答，还能关联到 PR 讨论。 - **代码评审**：基础设施的变更和业务代码一样，需要经过 Review 才能合并，"谁都能直接改生产"这种事在流程上就被堵死了。 - **回滚**：回滚不是"祈祷加祈祷"，而是 `git revert`。回滚本身也是一次有记录的变更。 - **分支与环境**：用 `main`、`staging`、`prod` 等分支（或者用 Kustomize 的 overlay、Helm 的 values 文件）来管理不同环境，结构清晰且复用度高。 - **不可否认性**：Git 的哈希链让历史不可篡改，这对于合规和安全审计场景来说价值巨大。 换句话说，GitOps 把运维变更纳入了现代软件工程已经验证过千万次的流程里。 ## 为什么是"持续调和"？ 这是很多人忽视、但却是 GitOps 真正的"魔法"所在。 传统的 CI/CD 流水线是**推送式（push）**的：流水线运行、执行 `kubectl apply`，然后就"完成"了。但"完成"只是意味着命令执行成功，**不等于**集群现在正处在你想要的状态。有人手动 `kubectl edit` 改了个镜像标签怎么办？有人误删了一个 ConfigMap 怎么办？节点故障导致 Pod 重建用了旧配置怎么办？ GitOps 引入了**拉取式（pull）**的调和循环： 1. 控制器（比如 Argo CD 或 Flux）持续 watch Git 仓库和集群实际状态。 2. 对比两者，计算差异（drift）。 3. 一旦发现偏差，自动将集群修正回期望状态；如果是 Git 仓库变了，则把变更同步到集群。 这就是所谓的 **自愈（self-healing）**。你的集群不再是一个"部署完就开始慢慢偏离轨道"的黑盒，而是一个始终被拉回正轨的系统。 推送模型是"我希望它变成这样"；拉取调和模型是"它必须是这样"。后者在可靠性上的差距是数量级的。 ## 生态中的代表工具 ### Argo CD [Argo CD](https://argo-cd.readthedocs.io/) 是 CNCF 毕业项目，也是最早让 GitOps 概念出圈的工具之一。它把"期望状态 vs 实际状态"的对比做成了一个可视化界面，你可以清楚地看到每个应用的同步状态（Synced / OutOfSync）、健康状况，以及精确到字段级别的差异。它原生支持 Helm、Kustomize、JSONNet 和裸 YAML，还提供了强大的 RBAC、SSO 集成和多租户能力。对于团队来说，Argo CD 往往是引入 GitOps 的第一站。 ### Flux [Flux](https://fluxcd.io/) 同样是 CNCF 毕业项目，由 Weaveworks 发起（后由控制平面团队继续维护）。与 Argo CD 偏"平台化"不同，Flux 更强调**可组合性**：它由一组专门的控制器组成——`source-controller`、`kustomize-controller`、`helm-controller`、`notification-controller` 等，各自负责一件事，可以按需组合。Flux 原生采用 Kustomize 作为配置管理层，并且与 Kubernetes 的 API 体系深度集成（比如通过 `Kustomization` 自定义资源来管理同步）。如果你喜欢 Unix 哲学式的工具设计，Flux 会很合你的胃口。 两者并不互斥，很多组织会根据场景混合使用。它们的共同点是都实现了相同的 GitOps 原则：**声明式配置、版本化存储、自动调和**。 ## 那么，GitOps 到底解决了什么问题？ 把上面的内容归纳一下，GitOps 的收益主要集中在四个维度： 1. **速度**：变更流程标准化后，从提交到上线的周期大幅缩短，工程师不需要在发布窗口等待运维窗口。 2. **可靠性**：幂等的声明式操作 + 持续调和，消除了配置漂移和"手工操作失误"这两大故障源。 3. **安全性**：集群凭证不再分发给每个开发者，只有控制器持有部署权限；变更必须走 PR，天然可审计。 4. **可恢复性**：灾难恢复的剧本简化为"把 Git 仓库里的配置重新同步到新集群"。新集群从零到完全就绪，可以是全自动的。 ## 一些值得提前思考的问题 GitOps 不是银弹，在采用前值得认真考虑： - **密钥管理**：Git 里不应该存放明文密钥。通常结合 Sealed Secrets、SOPS 或 External Secrets Operator 来解决。 - **仓库结构**：单仓库（monorepo）还是多仓库？环境如何建模？这些决策影响后续的维护成本。 - **初始状态**：已经存在的非声明式创建的资源，导入 Git 管理时需要做一次"接管"操作，过程要小心。 - **学习曲线**：团队需要理解"不直接改集群"的纪律，这有时比技术本身更难。 ## 结语 GitOps 之所以有效，是因为它没有发明什么新东西——它只是把 Git、声明式 API 和控制器模式这三个已经被反复验证的模式，组合成了一个完整的工作流。它把"运维"从一系列脆弱的手工动作，变成了一个有版本、有评审、有自动调和的工程系统。 如果你还没有试过，一个很好的起点是：**把你当前一个环境的 Kubernetes 清单放进 Git，装上 Argo CD 或 Flux，看着它把集群同步成仓库里的样子。** 从那一刻起，你就不会再想回到从前。

我构建了ARGO，一个开源Agent Loop框架，用于可追踪的AI编码交付

Reddit r/AI_Agents

作者介绍了ARGO，这是一个面向Cursor、GitHub Copilot和OpenCode的开源Agent Loop框架，它将ArchiMate结构化的意图图与GraphRAG检索相结合，使AI编码交付可追踪。它分离了意图、架构和实现的责任，并通过两级验收测试来避免将每次失败都视为代码缺陷。

nixidy 简介 - 使用 Nix 进行 Kubernetes GitOps

Lobsters Hottest

nixidy 是一个基于 Nix 的工具，用于管理 Kubernetes GitOps 部署，它用类型化、可复现的 Nix 表达式替代了 Helm 值文件和 Kustomize 覆盖层。本教程将介绍如何使用 Argo CD 设置 nixidy 项目，并生成纯 YAML 以供审查。

我们希望你基于 Cloudflare 构建下一代 Git 平台

Hacker News Top

Cloudflare 宣布 Artifacts（一个 Git 兼容、可随 AI 智能体扩展的版本化文件系统）进入公开测试阶段，新增 Workers Build/Preview 集成，并发起一项竞赛，邀请开发者基于 Cloudflare 构建面向 AI 智能体驱动的软件开发的下一代 Git 平台。