3. ArgoCD 基础架构：组件、部署模式与高可用设计
ArgoCD 作为 GitOps 实践的核心引擎，其架构设计直接决定了交付链路的稳定性与扩展性。理解 ArgoCD 的三大核心组件、常见的部署拓扑以及高可用保障策略，是进行资源配额校准与故障排查的前提。本章将深入剖析 ArgoCD 的内部运行机制。
3.1 核心组件与职责
ArgoCD 采用微服务架构，主要由 API Server、Repo Server 和 Application Controller 三个组件构成。它们各司其职，协同完成从代码仓库到 Kubernetes 集群的状态同步。
核心原则： ArgoCD 的每个组件都是无状态的（除缓存外），这为水平扩展和高可用部署提供了基础。
| 组件名称 | 核心职责 | 关键特性 |
|---|---|---|
| API Server | 暴露 gRPC/REST API，处理用户认证、授权、Webhook 及 UI 请求。 | 所有外部交互的入口；支持 SSO（OIDC/OAuth2）；管理 RBAC 策略。 |
| Repo Server | 克隆 Git 仓库，生成并缓存 Kubernetes 清单（Manifest）。 | 执行 helm template、kustomize build 等操作；维护本地缓存以加速同步。 |
| Application Controller | 持续监控集群状态，对比期望状态（来自 Repo Server）与实际状态，执行同步操作。 | 核心控制循环；处理自愈、自动同步、资源 Hook 等逻辑。 |
3.2 组件交互流程与架构图
下图展示了 ArgoCD 核心组件之间的数据流与交互关系。用户通过 API Server 发起操作，Repo Server 负责从 Git 获取配置，Application Controller 负责将配置应用到目标集群。
3.3 部署模式
根据组织规模和管控需求，ArgoCD 支持多种部署模式。选择合适的模式是保障 GitOps 流程顺畅的关键。
- 单集群模式（Core 模式）： 仅安装
argocd命名空间下的核心组件，管理自身所在集群。适用于小团队或单一环境。 - 多集群模式（标准模式）： 一个 ArgoCD 实例（控制面）管理多个目标集群。控制面与目标集群分离，通过
argocd cluster add注册集群凭据。这是生产环境最常用的模式。 - App of Apps 模式： 通过一个根 Application 递归部署多个子 Application，实现大规模应用编排。常用于微服务架构或环境级（dev/staging/prod）部署。
- 多租户模式： 通过 ArgoCD 项目的 RBAC 和命名空间隔离，实现不同团队共享同一个 ArgoCD 实例，但只能管理各自授权的应用和集群。
最佳实践： 对于生产环境，强烈建议采用多集群模式，将 ArgoCD 控制面部署在独立的“管理集群”中，避免因业务集群故障导致 GitOps 控制面不可用。
3.4 高可用设计
ArgoCD 的高可用设计主要围绕组件冗余、数据持久化和负载均衡展开。下表总结了关键组件的 HA 策略。
| 组件 | 高可用策略 | 关键配置 |
|---|---|---|
| API Server | 多副本部署 + 水平 Pod 自动扩缩（HPA） | 设置 --insecure 或配置 TLS；使用 Service 负载均衡 |
| Repo Server | 多副本部署 + 共享持久卷（PVC）或 Redis 缓存 | 配置 --repo-server-timeout-seconds；启用 argocd-repo-server 的并行处理 |
| Application Controller | 多副本部署 + 领导者选举（Leader Election） | 设置 --status-processors 和 --operation-processors 参数 |
| Redis | 哨兵模式（Sentinel）或 Redis Cluster | 用于缓存 Repo Server 的清单和 API Server 的会话 |
| 数据库 | 使用外部高可用数据库（如 RDS、Cloud SQL）替代内置 SQLite | 配置 argocd-secret 中的 redis.password 和数据库连接串 |
3.5 高可用部署架构图
下图展示了一个典型的生产级 ArgoCD 高可用部署架构。控制面组件均采用多副本，并通过 Service 和 Leader Election 保证服务连续性。
3.6 关键配置示例
以下是一个生产级 ArgoCD 高可用部署的 argocd-cm ConfigMap 关键配置片段，展示了如何调整控制器并发度与超时参数。
apiVersion: v1
kind: ConfigMap
metadata:
name: argocd-cm
namespace: argocd
data:
# 控制器并发处理状态同步的 worker 数量
controller.status.processors: "20"
# 控制器并发处理操作（如同步、回滚）的 worker 数量
controller.operation.processors: "10"
# Repo Server 超时时间（秒），防止大仓库超时
repo.server.timeout.seconds: "300"
# 允许同时运行的同步操作数量
controller.sync.parallel.limit: "5"
# 启用集群缓存，减少 API Server 对集群的请求
cluster.cache.enabled: "true"
注意： 调整
controller.status.processors 和 controller.operation.processors 时，需根据集群规模和节点资源进行压测。过高的并发值可能导致 API Server 或 etcd 过载。