ArgoCD 简介
1. 什么是 Argo CD
Argo CD 是针对 Kubernetes 的声明式 GitOps 持续交付工具。
官方文档：https://argo-cd.readthedocs.io
源码地址：https://github.com/argoproj/argo-cd
1.1 关于 Argo 项目
Argo 是一个开源项目，主要扩展 Kubernetes 的原生功能，让应用更好地运行在 Kubernetes 平台上。
GitHub 地址：https://github.com/argoproj
目前 Argo 包含多个子项目：
| 工具名称 | 类别 | 功能简介 | 关键备注 |
|---|---|---|---|
| Argo Workflows | 核心子项目 | 基于容器的工作流编排工具，可管理复杂的并行任务（如CI/CD流水线、机器学习）。 | CNCF 毕业项目 |
| Argo CD | 核心子项目 | 声明式GitOps持续交付工具，也是你提到的”本文主角”。 | CNCF 毕业项目 |
| Argo Events | 核心子项目 | 事件驱动工具，可基于各种事件源触发Kubernetes资源。 | CNCF 毕业项目 |
| Argo Rollouts | 核心子项目 | 支持金丝雀、蓝绿等渐进式发布策略。 | CNCF 毕业项目 |
| Argo CD Image Updater | 周边扩展工具 | 自动更新由 Argo CD 管理的应用镜像版本。它会检测镜像仓库的新版本，并更新 Argo CD 应用参数。 | 支持 Helm/Kustomize 应用，可写回 Git |
| Argo CD ApplicationSet | 周边扩展工具 | 通过模板批量管理多个 Argo CD 应用，支持多集群部署、从单仓库生成多个应用等场景。 | 通过 ApplicationSet CRD 实现 |
| Argo CD Autopilot | 周边扩展工具 | 用于自动化安装、配置和管理 Argo CD 及其应用的工具，帮助用户快速遵循 GitOps 实践。 | 简化了 Argo CD 的运维 |
| Argo CD Operator | 周边扩展工具 | 管理 Argo CD 的完整生命周期（安装、升级、备份、扩缩容等），简化运维。 | 旨在自动化 Argo CD 的集群操作 |
| Argo Vault Plugin | 周边扩展工具 | 用于从 HashiCorp Vault 等密钥管理工具中安全地注入密钥到 Argo CD 管理的应用。 | 增强 GitOps 工作流的安全性 |
| Argo CD Agent | 周边扩展工具 | 一种新的扩展组件，用于提升 Argo CD 在超大规模多集群环境下的可扩展性。 | 在 Red Hat OpenShift GitOps 1.19 中作为 GA 功能引入 |
1.2 Argo CD 简介
Argo CD 被实现为 Kubernetes 控制器，持续监控正在运行的应用程序，并将当前实时状态与期望目标状态（如 Git 仓库中的定义）进行比较。
若已部署应用的实时状态与目标状态存在偏差，则被视为 OutOfSync。Argo CD 会报告并可视化这些差异，同时提供将实时状态自动或手动同步回目标状态的功能。
对 Git 仓库中目标状态所做的任何修改，都可以自动应用并反映到指定的目标环境中。
1.3 Argo CD 核心特性
- 声明式管理：开发者只需在 Git 仓库中定义应用的期望状态，Argo CD 自动将集群的实际状态与之同步，减少人为错误，配置管理更清晰可审计
- GitOps 工作流：以 Git 仓库作为配置管理的唯一真理来源（Source of Truth），每次部署或更新都通过提交代码和合并请求触发，保证自动化与审核跟踪
- 持续同步与自愈：持续监控 Kubernetes 集群中的资源状态，检测到偏差时自动纠正，始终保持与 Git 仓库配置一致
- 多集群支持：可管理多个 Kubernetes 集群，跨集群的应用部署和管理更加便捷
- 细粒度访问控制：支持基于角色的访问控制（RBAC）及 SSO 集成，精细控制对特定项目和应用的访问权限
1.4 Argo CD vs Jenkins
| 功能 | Argo CD | Jenkins |
|---|---|---|
| 架构 | 专注于 Kubernetes 集群的声明式部署 | 通用的 CI/CD 工具，支持多种语言和环境 |
| GitOps 支持 | 内置支持 GitOps，Git 是唯一真理来源 | 需通过插件或自定义脚本支持 GitOps |
| 部署自动化 | 自动同步 Kubernetes 资源配置，持续保持集群一致性 | 通过流水线（Pipeline）手动配置部署过程 |
| 可观测性和回滚 | 内置监控和自动回滚功能 | 通过第三方工具或插件实现 |
| 插件支持 | 提供基础功能，无需大量插件 | 插件种类丰富，通过插件扩展功能 |
| CI/CD 整合 | 专注于 CD，通常与 Argo Workflows 等工具整合 | 同时支持 CI 和 CD，整合度较高 |
2. GitOps
2.1 基础设施即代码（IaC）
在理解 GitOps 之前，需要先了解**基础设施即代码（Infrastructure as Code, IaC）**的概念。
基础设施即代码表示使用代码来定义基础设施，研发人员可以像对待应用软件一样对待基础设施：
- 创建包含基础架构规范的声明式配置文件，便于编辑和分发配置
- 确保每次配置的环境完全一致
- 支持版本控制
- 将基础设施划分为若干模块化组件，通过自动化以不同方式进行组合
2.2 什么是 GitOps
GitOps = IaC + Git + CI/CD，即基于 IaC 的版本化 CI/CD。其核心是使用 Git 仓库管理基础设施和应用的配置，以 Git 仓库作为基础设施和应用的单一事实来源。
Git 仓库中的声明式配置描述了目标环境所需基础设施的期望状态。借助 GitOps，若集群的实际状态与 Git 仓库中定义的期望状态不匹配，Kubernetes Reconciler 会自动调整当前状态，最终使实际状态与期望状态一致。
2.3 GitOps vs DevOps
从广义上看，GitOps 与 DevOps 并不冲突：
- DevOps 是一种文化，关注最佳实践，可应用于企业每一个流程
- GitOps 是一种技术手段，是实现持续交付、持续部署和基础设施即代码的工具与框架，支撑 DevOps 文化
主要区别：
| GitOps | DevOps | |
|---|---|---|
| 目标导向 | 使用 Git 维护期望状态，不断调整实际状态使其与期望状态匹配 | 关注最佳实践，应用于企业每个流程 |
| 操作方式 | 采用声明式操作方法 | 同时接受声明式和命令式方法 |
2.4 ArgoCD 的优势
- Git 作为唯一真实来源：期望状态的唯一存储，配置变更有完整记录可追溯
- 快速回滚：通过 Git History 切换 commit，将应用状态快速恢复到上一个可用状态
- 集群灾备：若集群 A 出现故障，只需创建新集群并将 Argo CD 连接到包含集群 A 所有配置声明的 Git 仓库，新集群 B 的状态会自动与旧集群一致，无需人工干预
3. ArgoCD 架构
从功能架构看，Argo CD 主要包含三个核心组件：API Server、Repository Server 和 Application Controller。
从 GitOps 工作流角度，整个流程分为三个阶段：检索 → 调谐 → 呈现。
3.1 检索阶段 - Repository Server
检索阶段会克隆应用声明式配置清单所在的 Git 仓库，并将其缓存到本地存储。支持以下配置格式：
- Kubernetes 原生配置清单（YAML/JSON）
- Helm Chart
- Kustomize 配置清单
履行这些职责的组件是 Repository Server。
3.2 调谐阶段 - Application Controller
调谐（Reconcile）阶段将 Repository Server 获取的配置清单与反映集群当前状态的实时配置清单进行对比。一旦检测到应用处于 OutOfSync 状态，Application Controller 就会采取修正措施，使集群的实际状态与期望状态保持一致。
3.3 呈现阶段 - API Server
最后阶段由 API Server 负责，它是一个 gRPC/REST Server，提供无状态的可视化界面，用于展示调谐阶段的结果，并对外暴露 Web UI、CLI 及第三方工具所需的 API 接口。
部分信息可能已经过时