2. Argo CD架构总览

Argo CD 的架构设计遵循了云原生领域经典的控制平面与数据平面分离原则。这种设计使得 Argo CD 能够在一个集中的控制中心管理多个 Kubernetes 集群，同时保持对目标集群的最小侵入性。控制平面负责决策、状态存储和 API 暴露，而数据平面（即被管理的集群）仅运行一个轻量级的 Agent 来执行同步操作。

2.1 控制平面与数据平面分离设计

在 Argo CD 的架构中，控制平面通常部署在一个独立的 Kubernetes 集群（称为 Argo CD 集群 或 Hub 集群）上，而数据平面则是被管理的多个目标集群（Spoke 集群）。控制平面通过 API 与用户交互，并通过 SSH 或 方式与目标集群的 API Server 通信。

2.2 核心组件详解

Argo CD 的控制平面由四个核心组件构成，它们各司其职，共同构成了一个完整的事件驱动型 GitOps 引擎。

2.2.1 API Server

• 角色： 整个系统的入口，对外暴露 REST 和 gRPC 接口。
• 功能：
  • 处理来自 Web UI、CLI（argocd）和 CI/CD 系统的请求。
  • 执行认证与授权（RBAC、OIDC、LDAP、SSO）。
  • 代理对 Application Controller 和 Repo Server 的调用。
  • 提供应用状态查询、同步触发、项目管理和设置配置等操作。
• 无状态设计： API Server 是无状态的，可以水平扩展以应对高并发请求。

2.2.2 Repo Server

• 角色： Git 仓库的本地缓存和渲染引擎。
• 功能：
  • 克隆并缓存 Git 仓库内容，减少对远程仓库的频繁访问。
  • 生成（Generate）并渲染（Render） Kubernetes 清单文件。支持 Helm、Kustomize、Jsonnet 等配置管理工具。
  • 为 Application Controller 提供最终的、可应用的 Kubernetes 资源清单。
• 安全隔离： Repo Server 是唯一需要访问 Git 仓库的组件，其他组件通过它间接获取配置，降低了凭证泄露风险。

2.2.3 Application Controller

• 角色： 核心的“差异检测”与“同步”引擎。
• 功能：
  • 持续监控 Application 资源对象的状态。
  • 比较目标状态（来自 Repo Server 的清单）与当前状态（目标集群中的实际资源）。
  • 当检测到差异时，触发自动或手动同步操作，将集群状态修正为目标状态。
  • 管理应用的生命周期（创建、更新、回滚、删除）。
• 多集群管理： 每个 Application Controller 实例可以管理多个目标集群，通过集群 Secret 中存储的凭据进行通信。

2.2.4 Redis

• 角色： 高性能的内存缓存数据库。
• 功能：
  • 缓存 Repo Server 生成的清单，避免重复渲染。
  • 缓存 API Server 的查询结果，提升响应速度。
  • 作为组件间通信的临时存储和消息队列（例如，用于存储同步操作的状态）。
• 高可用： 在生产环境中，建议使用 Redis Sentinel 或 Redis Cluster 来保证缓存层的高可用性。

2.3 组件协作流程

以下是一个典型的 GitOps 工作流程，展示了四个核心组件如何协同工作：

1. 用户提交代码 到 Git 仓库，修改了 Kubernetes 清单文件。
2. Repo Server 定期轮询或通过 Webhook 感知到仓库变更，拉取最新代码并渲染清单。
3. Application Controller 从 Repo Server 获取最新的目标状态，并与目标集群中的当前状态进行对比。
4. Application Controller 检测到差异，根据同步策略（自动或手动）执行同步操作。
5. Application Controller 通过 Kubernetes API 将更新后的资源清单应用到目标集群。
6. API Server 将最新的应用状态和同步结果存储到 Redis 中，并通过 UI/CLI 展示给用户。