2. Argo CD 核心架构
Argo CD 遵循 控制平面（Control Plane） 与 工作集群（Workload Cluster） 分离的云原生设计模式。控制平面本身是一个 Kubernetes 原生应用，运行在专用的集群（通常称为 Argo CD 集群）中，通过五大核心组件协同工作，实现对远端目标集群的 GitOps 持续交付。
下图展示了 Argo CD 控制平面的整体架构与组件间通信关系：
2.1 控制平面（Control Plane）
控制平面是 Argo CD 的大脑，负责管理所有 Application 的生命周期。它不直接运行用户业务负载，而是通过 Application Controller 与目标集群的 API Server 通信，确保远端集群的实际状态与 Git 仓库中的期望状态一致。
| 特性 | 说明 |
|---|---|
| 部署位置 | 专用集群（Argo CD 集群）或与工作负载共享集群 |
| 高可用 | 支持多副本部署，通过 Redis 共享会话与缓存 |
| 多集群管理 | 通过 kubeconfig 或 Service Account 连接任意数量的目标集群 |
| 安全边界 | 控制平面组件间使用 TLS 通信，API Server 提供 RBAC 与 SSO 集成 |
2.2 API Server
API Server 是 Argo CD 的入口组件，对外暴露 REST 和 gRPC 接口。所有用户操作、CI/CD 系统调用、Web UI 请求都通过 API Server 进行。
- 认证与授权：支持本地用户、OIDC、LDAP、GitHub/GitLab SSO，以及 Kubernetes Service Account 认证。
- RBAC 策略：基于项目（Project）的细粒度权限控制，支持角色绑定到用户或组。
- 项目管理：创建和管理 Application、Project、Repository、Cluster 等 CRD 资源。
- Web UI 与 CLI：提供图形化界面和
argocd命令行工具，底层均调用 API Server。
最佳实践： 在生产环境中，建议为 API Server 配置 TLS 证书和外部 Ingress，并启用 OIDC 集成，避免使用本地 admin 账号。
2.3 Repository Server
Repository Server 负责与 Git 仓库交互，是 Argo CD 获取期望状态的唯一来源。它内部维护了一个本地缓存，避免每次同步都重新克隆仓库。
| 功能 | 详细说明 |
|---|---|
| 仓库克隆与更新 | 支持 HTTPS、SSH 认证，定期 git fetch 保持缓存最新 |
| 清单生成 | 支持 Helm Chart、Kustomize、Jsonnet 等模板引擎，渲染最终 Kubernetes 清单 |
| 目录遍历 | 递归扫描仓库路径，发现所有 Application 对应的清单文件 |
| 缓存策略 | 使用 Redis 或本地文件系统缓存已生成的清单，减少重复计算 |
注意： Repository Server 需要访问 Git 仓库的权限。建议使用 Deploy Key（只读）或 Service Account ，避免使用个人账号密码。
2.4 Application Controller
Application Controller 是 Argo CD 的核心执行引擎，运行一个持续的控制循环，负责将目标集群的实际状态与 Git 仓库中的期望状态进行比对，并执行同步操作。
- 状态比较（Diff）：定期（默认 3 分钟）或通过 Webhook 触发，对比
Desired State与Live State。 - 自动同步：当检测到差异时，根据
syncPolicy自动执行同步，或等待手动批准。 - 资源生命周期管理：创建、更新、删除 Kubernetes 资源，支持 Prune（清理）已从 Git 中移除的资源。
- 健康状态评估：内置多种资源健康检查规则（如 Deployment 的 Available 状态），并支持自定义健康检查。
2.5 Redis
Redis 在 Argo CD 中扮演缓存和状态共享层的角色，是支撑控制平面高可用和性能的关键组件。
| 用途 | 说明 |
|---|---|
| 会话存储 | 存储用户登录会话和 JWT ，支持 API Server 多副本 |
| 操作锁 | 防止多个 Application Controller 实例同时操作同一个 Application |
| 清单缓存 | 缓存 Repository Server 生成的 Kubernetes 清单，减少重复渲染 |
| 状态缓存 | 缓存目标集群的实时状态，加速差异比较 |
高可用部署： 生产环境建议使用 Redis Sentinel 或 Redis Cluster 模式，避免单点故障。Argo CD 官方 Helm Chart 默认部署单实例 Redis，可通过
--set redis-ha.enabled=true 启用高可用模式。
2.6 组件间通信总结
下表总结了五大组件之间的通信方式与数据流向：
| 源组件 | 目标组件 | 通信协议 | 数据内容 |
|---|---|---|---|
| 用户/CI | API Server | REST/gRPC | 创建/更新/同步 Application |
| API Server | Repository Server | gRPC | 请求清单生成 |
| API Server | Application Controller | gRPC | 触发同步、查询状态 |
| API Server | Redis | TCP | 读写会话、缓存 |
| Application Controller | 目标集群 | Kubernetes API | 读取/写入资源 |
| Repository Server | Git 仓库 | HTTPS/SSH | 克隆、拉取代码 |
架构要点： API Server 是唯一对外暴露的组件，Repository Server 和 Application Controller 不直接对外提供服务。这种设计将安全边界收敛到 API Server，简化了网络策略和防火墙配置。