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

Argo CD 采用微服务架构，由四个核心组件构成：API Server、Repo Server、Application Controller 和 Redis。每个组件职责单一、可独立扩缩容，组件之间通过 gRPC / HTTP 协议协同工作，共同实现 GitOps 配置的声明式同步。

2.1 组件职责与功能矩阵

组件 核心职责 对外暴露端口 关键特性
API Server REST/gRPC 网关、认证授权、Web UI、CLI 入口 443 (HTTPS) / 8080 (HTTP) RBAC、SSO 集成、审计日志
Repo Server Git 仓库克隆、清单生成、Helm/Kustomize 渲染 8081 (gRPC) 仓库缓存、SSH/HTTPS 凭证管理
Application Controller 状态对比、差异计算、自动/手动同步执行 8082 (metrics) 多集群管理、健康检查、Sync 策略
Redis 缓存、会话存储、应用状态快照 6379 可选高可用 Sentinel/Cluster
设计要点：Repo Server 是唯一直接访问 Git 仓库的组件，API Server 和 Application Controller 均通过 gRPC 调用 Repo Server 获取渲染后的清单，避免凭证扩散。

2.2 组件间通信流程

一次完整的配置同步请求涉及所有四个组件，典型时序如下：

  1. 用户触发：通过 CLI/UI/API 向 API Server 发起 Sync 请求。
  2. API Server 转发：将请求写入 Redis 队列，并通知 Application Controller。
  3. Controller 拉取：Application Controller 从 Redis 获取待同步任务，调用 Repo Server 生成目标清单。
  4. Repo Server 渲染：克隆仓库、执行 Helm template / Kustomize build，返回渲染后的 Kubernetes 资源清单。
  5. Controller 对比：将目标清单与集群当前状态对比，生成差异报告。
  6. Controller 执行：调用 Kubernetes API 应用变更，更新 Redis 中的状态缓存。
Argo CD 组件间通信流程（一次同步请求） 用户 CLI/UI API Server Redis Application
Controller Repo Server Kubernetes
集群 ① Sync 请求 ② 写入任务 ③ 拉取任务 ④ 生成清单 ⑤ 返回清单 ⑥ 应用变更 说明：所有 gRPC 调用均使用 TLS 加密；Redis 作为异步消息队列解耦 API Server 与 Controller。

2.3 高可用部署模式

生产环境必须消除单点故障。Argo CD 官方推荐以下高可用部署策略：

2.3.1 组件副本与反亲和性

组件 推荐副本数 Pod 反亲和策略 资源建议
API Server 2~3 软反亲和（preferred） 2 CPU / 4 GiB
Repo Server 2~3 硬反亲和（required） 4 CPU / 8 GiB
Application Controller 2~3 硬反亲和（required） 2 CPU / 4 GiB
Redis 3 (Sentinel) / 6 (Cluster) 硬反亲和（required） 1 CPU / 2 GiB
关键配置示例（application-controller 反亲和）： 
affinity:
  podAntiAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
    - labelSelector:
        matchExpressions:
        - key: app.kubernetes.io/component
          operator: In
          values:
          - application-controller
      topologyKey: kubernetes.io/hostname

2.3.2 多副本下的状态一致性

  • API Server：无状态，所有会话状态存储在 Redis 中，任意副本可处理请求。
  • Repo Server：无状态，但每个副本维护本地 Git 缓存；通过共享持久卷（ReadWriteMany）或独立缓存 + 一致性哈希避免重复克隆。
  • Application Controller：有状态分片模式，每个 Controller 副本负责一部分 Application 的同步；通过 Redis 中的分片锁（sharding lock）协调。
  • Redis：使用 Redis Sentinel 或 Redis Cluster 实现自动故障转移，避免缓存丢失导致全量重新计算。

2.4 高可用部署架构图

Argo CD 高可用部署架构 负载均衡器 (LB) API Server Pod 1 API Server Pod 2 API Server Pod 3 Redis Sentinel 集群 Controller Pod 1 Controller Pod 2 Controller Pod 3 Repo Server Pod 1 Repo Server Pod 2 说明：API Server 和 Repo Server 为无状态水平扩展；Controller 通过 Redis 分片锁实现有状态分片；Redis Sentinel 保障缓存高可用。

2.5 关键设计决策

避坑指南：
  • 不要将 Repo Server 副本数设为 1，否则 Git 克隆操作会成为性能瓶颈。
  • Controller 的分片数应小于等于 Redis 可用连接数，避免连接池耗尽。
  • Redis 必须配置持久化（AOF + RDB），否则重启后所有 Application 状态需要重新计算。
  • 多集群场景下，每个目标集群的 kubeconfig 凭证应通过 Argo CD 的 cluster secret 管理，不要硬编码到 Repo Server 中。

2.6 组件间协议与端口汇总

源组件 目标组件 协议 端口 用途
API Server Redis TCP 6379 会话/缓存读写
API Server Repo Server gRPC (TLS) 8081 仓库测试、清单预览
Application Controller Repo Server gRPC (TLS) 8081 获取渲染清单
Application Controller Redis TCP 6379 状态缓存、分片锁
Application Controller Kubernetes API HTTPS 6443 同步资源
← 上一章 📖 返回目录 下一章 →