2. Argo CD 核心架构：组件、数据流与工作原理
Argo CD 遵循 声明式 GitOps 模式，其核心架构由三个主要组件构成：API Server、Repo Server 和 Application Controller。这三个组件协同工作，将 Git 仓库中的期望状态持续同步到目标 Kubernetes 集群。
2.1 核心组件与职责
| 组件 | 核心职责 | 关键特性 |
|---|---|---|
| API Server | Argo CD 的入口网关，处理所有外部请求（CLI、UI、API）。 | 认证鉴权、RBAC、应用管理、Webhook 接收、Project 管理。 |
| Repo Server | 负责与 Git 仓库交互，生成目标 Kubernetes 清单。 | 仓库缓存、多仓库支持、Helm/Kustomize/Ksonnet 渲染、SSH/HTTPS 凭证管理。 |
| Application Controller | 核心调度引擎，持续对比期望状态与实时状态并执行同步。 | 状态差异计算、自动/手动同步、健康状态评估、资源生命周期管理。 |
架构要点：三个组件均为无状态设计（Repo Server 有缓存），可通过 HPA 水平扩展。API Server 和 Application Controller 直接与 Kubernetes API 交互，Repo Server 仅与 Git 仓库通信。
2.2 组件间数据流与工作原理
下图展示了 Argo CD 在一次完整同步周期中的核心数据流：
2.3 同步周期详细步骤
- 触发同步：用户通过 CLI/UI/API 发起同步请求，或 Git Webhook 自动触发。
- 请求清单：API Server 将请求转发给 Repo Server，指定目标仓库、分支、路径。
- 拉取与渲染：Repo Server 从 Git 仓库拉取最新代码，执行 Helm/Kustomize 渲染，生成纯 Kubernetes 清单。
- 返回清单：Repo Server 将渲染后的清单返回给 API Server 并缓存。
- 传递清单：Application Controller 从 API Server 获取期望清单。
- 差异计算：Application Controller 对比期望清单与目标集群当前状态，生成差异报告。
- 执行同步：Application Controller 调用目标集群 API，执行 create/update/delete 操作。
- 状态反馈：Application Controller 持续监控同步结果，更新应用健康状态。
性能关键点：Repo Server 的缓存机制和 Application Controller 的差异计算效率直接影响大规模集群的同步速度。在压测场景中，Repo Server 的并发拉取能力和 Application Controller 的清单对比性能是主要瓶颈。
2.4 组件间通信协议
| 通信路径 | 协议 | 端口 | 说明 |
|---|---|---|---|
| 用户 → API Server | HTTPS / gRPC | 443 / 8080 | 外部访问入口，支持 REST 和 gRPC |
| API Server → Repo Server | gRPC (TLS) | 8081 | 内部服务间通信，传输清单请求 |
| API Server → Application Controller | gRPC (TLS) | 8082 | 传递同步指令和状态查询 |
| Repo Server → Git 仓库 | SSH / HTTPS | 22 / 443 | 拉取仓库代码，支持多仓库 |
| Application Controller → 目标集群 | HTTPS (K8s API) | 6443 | 直接调用 Kubernetes API |
2.5 关键设计原则
- 无状态设计：所有组件均可水平扩展，状态存储在 Kubernetes CRD 和 Redis（可选）中。
- 缓存优先：Repo Server 缓存渲染后的清单，减少 Git 仓库压力。
- 最终一致性：Application Controller 通过轮询或 Webhook 触发同步，保证最终一致性。
- 安全隔离：Repo Server 不直接访问集群，Application Controller 不直接访问 Git，降低攻击面。
压测注意事项：在配额压测沙盘中，需要重点关注 Repo Server 的并发连接数限制和 Application Controller 的清单对比耗时。建议为 Repo Server 配置独立的资源配额，避免因 Git 拉取延迟影响整体同步性能。