2. Argo CD 架构解析：核心组件与工作流程

Argo CD 采用微服务架构，由三个核心组件协同工作，将 Git 仓库中的期望状态持续同步到目标 Kubernetes 集群。理解每个组件的职责与交互流程，是掌握 GitOps 回滚机制的基础。

2.1 核心组件总览

2.2 组件交互流程

下图展示了 Argo CD 处理一次 Git 变更到集群同步的完整数据流：

2.3 核心组件深度解析

2.3.1 API Server

• 身份认证与授权：集成 OIDC、LDAP、SAML，支持 RBAC 策略，所有操作必须经过 API Server 鉴权。
• Webhook 处理：接收 Git 仓库的 push 事件，触发自动同步（无需轮询）。
• CLI/UI 后端：提供 argocd 命令行工具和 Web 控制台的全部后端逻辑。
• 回滚入口：用户执行 argocd app rollback 时，请求首先到达 API Server。

2.3.2 Repo Server

• 清单生成引擎：支持 Helm、Kustomize、Jsonnet、纯 YAML 等多种配置管理工具。
• 缓存机制：将生成的 Kubernetes 清单缓存到内存中，避免每次对比都重新拉取仓库。
• 安全隔离：运行在独立的 Pod 中，即使被攻破也不会直接影响集群资源。
• 回滚关键：回滚时 Repo Server 根据历史 Commit SHA 重新生成对应版本的清单。

2.3.3 Application Controller

• 状态对比循环：默认每 3 分钟（可配置）对比一次 Git 期望状态与集群实际状态。
• 自动/手动同步：发现差异后，根据同步策略（自动/手动）执行资源创建、更新或删除。
• 回滚执行者：回滚操作本质上是将 Application 的 targetRevision 指向历史 Commit，然后执行同步。
• 健康评估：同步完成后检查资源健康状态（Progressing、Degraded、Healthy）。

2.4 工作流程详解

一个完整的 GitOps 工作流包含以下步骤：

1. 配置变更：开发者在 Git 仓库中修改 Kubernetes 清单文件并推送。
2. Webhook 触发：Git 仓库（GitHub/GitLab/Bitbucket）向 Argo CD API Server 发送 push 事件。
3. 清单刷新：API Server 通知 Repo Server 拉取最新代码并重新生成清单。
4. 状态对比：Application Controller 从 Repo Server 获取最新期望清单，与集群实际状态对比。
5. 差异执行：若存在差异，根据同步策略执行资源变更（自动同步立即执行，手动同步等待用户确认）。
6. 状态更新：同步完成后，Application Controller 更新 Application 的状态（Synced/OutOfSync/Healthy/Degraded）。

2.5 回滚场景下的组件协作

当执行回滚操作时，组件协作流程略有不同：

2.6 组件高可用配置建议