2. Argo CD 核心架构:控制平面组件与数据平面概念

Argo CD 遵循 Kubernetes 原生的控制器模式,其核心架构由一组控制平面组件和一个逻辑上的数据平面构成。理解这些组件的职责及其通信机制,是设计项目级准入策略通信的基础。

2.1 控制平面三大核心组件

Argo CD 的控制平面由三个长期运行的微服务组成,它们协同工作以实现 GitOps 的声明式持续交付。

组件 核心职责 关键特性
API Server 暴露 REST/gRPC API,处理用户请求、认证授权、Webhook 触发 无状态、水平扩展、TLS 终止、RBAC 入口
Repo Server 克隆 Git 仓库、生成 Kubernetes 清单、缓存构建结果 有状态(缓存)、执行 helm template / kustomize build
Application Controller 持续对比期望状态(Git)与实际状态(集群),执行同步操作 有状态(informer 缓存)、管理 Application CRD 生命周期
架构要点: API Server 是用户和外部系统的唯一入口;Repo Server 是清单生成的“工厂”;Application Controller 是持续调谐的“引擎”。三者缺一不可。

2.2 数据平面概念

在 Argo CD 的语境中,数据平面并非指独立的网络代理,而是指被 Argo CD 管理的目标 Kubernetes 集群。这些集群承载着实际的业务工作负载,是 GitOps 交付的最终目的地。

  • 管理集群: 运行 Argo CD 控制平面组件的集群。
  • 目标集群: 被 Argo CD 管理的业务集群,可以是管理集群自身(in-cluster),也可以是外部集群。
  • 通信边界: 控制平面通过 kubeconfig 与目标集群的 API Server 通信,执行资源的创建、更新、删除操作。
设计启示: 准入策略的通信机制需要跨越“控制平面 → 数据平面”的边界。策略评估点(如 Webhook)可以部署在管理集群或目标集群,这决定了通信的延迟、安全性和故障域。

2.3 组件间通信基础

三大组件之间的通信是同步与异步混合的模式,理解这些通信路径对于设计安全、低延迟的准入策略至关重要。

  1. API Server → Repo Server: 当用户创建 Application 或触发同步时,API Server 通过 gRPC 调用 Repo Server 生成清单。这是同步调用,超时时间通常为 60 秒。
  2. Application Controller → Repo Server: 控制器定期(默认 3 分钟)或通过 Webhook 触发,调用 Repo Server 获取最新清单,用于状态对比。
  3. Application Controller → 目标集群: 控制器使用 kubeconfig 直接与目标集群的 API Server 通信,执行 diff 和 sync 操作。
  4. API Server → 目标集群: 用户通过 argocd app sync 或 UI 触发同步时,API Server 将请求转发给 Application Controller,由后者执行实际同步。
Argo CD 控制平面组件通信架构 管理集群(控制平面) API Server REST / gRPC 入口 Repo Server 清单生成 & 缓存 App Controller 状态调谐 & 同步 gRPC (同步) gRPC (同步) 事件 / 转发 (异步) 数据平面(目标集群) 目标集群 API Server kubeconfig 认证 kubeconfig (HTTPS) 说明:实线为同步 gRPC 调用,虚线为异步事件转发;所有跨集群通信均通过 HTTPS/TLS 加密

2.4 通信安全基础

在项目级准入策略设计中,组件间通信的安全性直接影响策略的信任模型。

  • mTLS: Repo Server 与 API Server 之间默认使用双向 TLS 认证,确保通信双方身份可信。
  • 认证: Application Controller 使用 Service Account 或静态 kubeconfig 访问目标集群, 的权限范围决定了控制器能执行的操作。
  • 网络策略: 建议在管理集群中部署 NetworkPolicy,仅允许必要的端口(API Server: 443, Repo Server: 8081/gRPC, Controller: 8082/metrics)通信。
安全风险提示: 如果 Repo Server 被攻破,攻击者可以篡改清单生成逻辑,从而绕过准入策略。因此,Repo Server 的缓存目录和 Git 凭证必须严格保护,建议启用加密存储。

2.5 通信超时与重试策略

准入策略的通信机制必须考虑超时和重试,以避免组件间调用阻塞导致整个同步流程卡死。

通信路径 默认超时 重试策略 对准入策略的影响
API Server → Repo Server 60s 指数退避,最多 3 次 清单生成阶段的 Webhook 必须在 60s 内完成
App Controller → Repo Server 30s 固定间隔重试(5s) 状态对比阶段的策略检查不能阻塞调谐循环
App Controller → 目标集群 30s 无重试(直接报错) 同步阶段的准入 Webhook 失败会导致同步失败
设计建议: 在项目级准入策略中,建议将策略评估点放在 Repo Server 的清单生成阶段(通过自定义插件或 Webhook),因为此时尚未对目标集群产生实际影响,失败成本最低。