2. Argo CD 架构回顾：核心组件与多集群管理模式
在深入高风险变更准入策略之前，必须重新理解 Argo CD 的架构设计。多租户隔离集群场景下的所有策略拦截点，都直接对应 Argo CD 核心组件的通信路径与数据流。本节从组件职责、通信链路、多集群管理模式三个维度进行架构回顾。
2.1 核心组件及其职责
Argo CD 由三个常驻组件构成，每个组件在 GitOps 工作流中承担不可替代的角色。下表列出各组件的核心职责、关键端口及数据存储依赖。
| 组件 | 核心职责 | 关键端口 | 数据存储 |
|---|---|---|---|
| API Server | 暴露 REST/gRPC API；处理用户认证、RBAC、Webhook；作为所有 CLI/UI 请求的入口 | 443 (HTTPS) | Redis（缓存）、Kubernetes CRD（Application/AppProject） |
| Repo Server | 克隆 Git 仓库；生成 Helm/Kustomize/Jsonnet 清单；缓存生成的 manifests | 8081 (gRPC) | 本地缓存目录、Redis（manifest 缓存） |
| Application Controller | 持续对比 desired state（来自 Repo Server）与 live state（来自目标集群）；执行 Sync/Prune 操作 | 8082 (metrics) | Kubernetes CRD（Application status） |
策略切入点提示： 三个组件中，API Server 是准入 Webhook 的天然锚点（用户提交 Application 时触发），Application Controller 是运行时变更的最终执行者。高风险变更策略需要在这两个组件之间建立双重校验。
2.2 组件间通信链路
下图展示 Argo CD 核心组件之间的数据流与通信协议。理解这条链路是配置准入策略的前提——策略必须部署在数据流的关键路径上。
2.3 多集群管理模式
Argo CD 支持三种多集群管理模式，不同模式对准入策略的部署位置和生效范围有直接影响。多租户隔离场景通常采用 Cluster Secret 模式 或 Argo CD 控制平面内嵌模式。
| 管理模式 | 实现方式 | 策略部署位置 | 适用场景 |
|---|---|---|---|
| Cluster Secret 模式 | 在 Argo CD 命名空间创建 Secret，包含目标集群的 kubeconfig |
策略引擎部署在 Argo CD 控制平面，对所有注册集群生效 | 多租户共享控制平面，每个租户对应一个 Cluster Secret |
| Argo CD 控制平面内嵌模式 | Argo CD 直接使用自身 ServiceAccount 管理集群 | 策略引擎作为 Argo CD 的 sidecar 或 webhook | 单租户或少量集群，控制平面与目标集群隔离要求不高 |
| 外部集群代理模式 | 通过 Argo CD 的 cluster API 注册外部集群，使用代理隧道通信 |
策略引擎需要同时部署在控制平面和代理节点 | 跨网络边界、防火墙隔离的集群管理 |
多租户隔离集群推荐模式： 使用 Cluster Secret 模式，每个租户集群拥有独立的 Secret，并在 Secret 中标注租户标签（如
tenant: team-a）。准入策略通过标签选择器匹配目标集群，实现租户级策略隔离。
2.4 多集群数据流与策略拦截点
下图展示多集群模式下，Argo CD 如何将 Application 分发到多个目标集群，并标注策略引擎的拦截位置。
2.5 架构要点总结
- API Server 是用户与 Argo CD 交互的唯一入口，所有 Application 的创建、更新、删除操作都经过 API Server。准入 Webhook 应注册在 API Server 侧。
- Repo Server 负责将 Git 仓库中的模板渲染为最终的 Kubernetes 清单。策略引擎可以在 manifest 生成后、同步前进行静态分析。
- Application Controller 是实际执行同步操作的组件。高风险变更策略需要在 Controller 向目标集群发起请求前进行二次校验。
- 多集群管理 的核心是 Cluster Secret 机制。每个 Secret 代表一个目标集群，租户隔离通过 Secret 的标签或命名空间实现。
常见架构误区： 不要将策略引擎直接部署在目标集群内部。在多租户场景下，目标集群可能不受 Argo CD 控制平面管理，策略引擎必须位于控制平面侧，确保策略的统一执行和审计。