2. Argo CD 核心架构回顾:组件分解与核心工作流

Argo CD 采用微服务架构,由四个核心组件协同完成从 Git 仓库到 Kubernetes 集群的声明式部署。理解每个组件的职责及其通信机制,是进行灾备设计与准入控制评审的基础。

2.1 组件分解与职责

组件 核心职责 关键特征
API Server REST API 网关、认证授权、Web UI/CLI 入口、RBAC 策略执行 无状态,可水平扩展;所有外部请求的唯一入口
Repo Server 克隆 Git 仓库、生成 Helm/Kustomize/Jsonnet 清单、缓存清单 有状态(本地 Git 缓存);计算密集型,需与 Git 仓库频繁通信
Application Controller 持续对比期望状态(Git)与实际状态(K8s)、执行同步操作 无状态,但需监听 K8s 资源变化;核心调度引擎
Redis 缓存 Git 清单、存储应用状态快照、API Server 会话管理 有状态;故障将导致性能下降或功能降级
架构要点:API Server 是唯一对外暴露的组件,Repo Server 和 Application Controller 不直接暴露端口。Redis 作为共享缓存层,是组件间数据交换的关键枢纽。

2.2 组件间通信机制

四个组件通过 gRPC 和 Redis Pub/Sub 两条主要通道进行通信,形成闭环工作流。

  • API Server ↔ Repo Server:通过 gRPC 调用获取渲染后的 Kubernetes 清单。Repo Server 将生成的清单缓存至 Redis,减少重复计算。
  • API Server ↔ Redis:存储用户会话、应用状态缓存、Git 清单缓存。API Server 通过 Redis 实现无状态化。
  • Application Controller ↔ Redis:订阅 Redis Pub/Sub 通道,接收来自 API Server 的同步请求通知;同时将应用状态快照写入 Redis。
  • Application Controller ↔ K8s API:直接通过 K8s API Server 监听资源变化并执行同步操作,不经过 Argo CD 内部组件。
通信安全提示:Repo Server 与 Git 仓库之间使用 SSH/HTTPS 认证;API Server 与 Repo Server 之间使用 TLS 双向认证;Redis 建议启用密码认证和 TLS 加密。

2.3 核心工作流:从 Git 提交到集群同步

下图展示了 Argo CD 处理一次应用同步请求的完整数据流:

Argo CD 核心工作流:从 Git 提交到集群同步 Argo CD 核心工作流:从 Git 提交到集群同步 Git 仓库 Repo Server Redis 缓存 API Server App Controller K8s 集群 用户 / CI 系统 拉取/克隆 缓存清单 gRPC 获取清单 读写缓存 同步请求 订阅通知 同步/监听 REST/gRPC 工作流步骤: ① 用户/CI 提交 Git ② Repo Server 拉取并渲染 ③ 清单缓存至 Redis ④ API Server 发起同步 ⑤ Controller 执行同步

2.4 工作流步骤详解

  1. 触发阶段:用户通过 CLI/UI 提交同步请求,或 Git Webhook 触发自动同步。API Server 接收请求并校验 RBAC 权限。
  2. 清单生成阶段:API Server 通过 gRPC 调用 Repo Server,Repo Server 从 Git 仓库拉取最新代码,执行 Helm template / Kustomize build 等操作,生成最终的 Kubernetes 清单。
  3. 缓存阶段:Repo Server 将生成的清单写入 Redis,并返回给 API Server。后续相同应用的请求可直接从 Redis 读取,避免重复计算。
  4. 同步调度阶段:API Server 将同步任务通过 Redis Pub/Sub 发布通知,Application Controller 订阅到消息后开始执行同步。
  5. 执行阶段:Application Controller 对比期望清单与集群实际状态,调用 K8s API 执行 create/update/delete 操作,并将同步结果写回 Redis。
灾备关注点:Redis 是单点故障风险最高的组件。若 Redis 宕机,API Server 无法获取缓存清单,Application Controller 无法接收同步通知,整个 Argo CD 将进入降级模式。生产环境必须为 Redis 配置高可用(Sentinel 或 Cluster)。

2.5 组件状态与扩展性对比

组件 状态类型 扩展方式 灾备策略
API Server 无状态 水平扩展(HPA) 多副本 + 负载均衡
Repo Server 有状态(本地缓存) 水平扩展(需共享 PVC 或使用 Redis 替代本地缓存) 多副本 + 共享缓存层
Application Controller 无状态(依赖 Redis) 水平扩展(分片策略) 多副本 + 分片协调
Redis 有状态 垂直扩展 / 集群模式 Sentinel 高可用 / Redis Cluster