Argo CD 基础：架构、核心组件及工作原理

Argo CD 是 Kubernetes 生态中最主流的声明式 GitOps 持续交付工具。理解其架构与核心组件，是后续编排标准模板变更风险评估任务的前提。本章从宏观架构切入，逐一拆解三大核心组件，并梳理端到端工作流程。

2.1 整体架构概览

Argo CD 采用 控制面 + 工作集群 的分离式架构。控制面通常部署在一个独立的 Kubernetes 集群（或命名空间）中，通过 API 与多个目标集群交互。其核心设计理念是：以 Git 仓库为唯一事实来源，通过持续对比期望状态（Git）与实际状态（K8s），自动或手动完成同步。

2.2 三大核心组件详解

Argo CD 控制面由三个核心组件构成，各自承担独立职责，通过 Kubernetes CRD（Custom Resource Definition）和控制器模式协同工作。

2.3 核心组件交互流程

一次完整的 Argo CD 同步操作，涉及三个组件与外部系统的协作。以下按步骤拆解：

1. 用户提交 Application 资源：通过 argocd app create 命令或 Web UI 创建 Application CRD，指定 Git 仓库路径、目标集群、同步策略等参数。API Server 将 Application 写入 Kubernetes etcd。
2. Application Controller 检测到新 Application：Controller 通过 Informer 机制监听 Application 资源变化，开始进入对比循环。
3. Controller 请求 Repo Server 生成 Manifests：Controller 调用 Repo Server 的 gRPC 接口，传入仓库 URL、分支、路径及模板参数。Repo Server 拉取代码，执行渲染（如 Helm template），返回纯 Kubernetes YAML 列表。
4. Controller 对比期望 vs 实际：Controller 将 Repo Server 返回的 Manifests 与目标集群中当前运行的资源进行深度对比（Diff）。对比结果包括：Synced（一致）、OutOfSync（不一致）、Missing（缺失）、Extra（多余）。
5. 执行同步操作：若策略为自动同步，Controller 直接调用 Kubernetes API 创建/更新/删除资源；若为手动同步，则等待用户通过 API Server 触发 Sync 操作。
6. 状态回写：Controller 将同步结果、健康状态、操作日志写回 Application 资源的 Status 字段。API Server 通过 Watch 机制将状态推送给 Web UI 和 CLI。

2.4 关键设计原则

• 声明式 Reconciliation 循环：Application Controller 内部运行一个无限循环，不断对比期望状态与实际状态，确保集群始终向 Git 中定义的状态收敛。这是 GitOps 的核心机制。
• 无状态组件 + 状态外置：三个核心组件本身不存储持久化数据。所有 Application 定义、同步历史、集群信息均存储在 Kubernetes 的 etcd 中，通过 CRD 暴露。这使得 Argo CD 控制面可以轻松重启、扩缩容而不丢失状态。
• 安全隔离：Repo Server 拥有访问 Git 仓库的凭证（SSH Key / ），但不会直接操作集群；Application Controller 拥有操作目标集群的权限，但无法直接访问 Git 仓库。API Server 负责统一的认证与授权入口。
• 插件化模板引擎：Repo Server 支持 Helm、Kustomize、Jsonnet 等主流模板工具，也支持自定义配置管理工具（CMT），通过 Config Management Plugins 机制扩展。

2.5 组件间通信方式