2. Argo CD 基础架构回顾：核心组件及其在事件流中的角色

在深入事件流还原之前，必须厘清 Argo CD 的三个核心组件——API Server、Repo Server 和 Application Controller。它们各自承担不同的职责，并通过 gRPC 和事件队列协同工作，构成 GitOps 自动化的执行引擎。理解每个组件在事件流中的位置，是后续分析灾备切换和蓝绿发布故障时间线的前提。

2.1 核心组件总览

下表从职责、通信方式、关键数据结构和在事件流中的角色四个维度，对三个组件进行对比：

2.2 组件详解与事件流定位

2.2.1 API Server — 事件入口

API Server 是 Argo CD 的“前门”，所有外部事件都首先到达这里：

• Git Webhook 事件：当开发者推送代码到 Git 仓库时，Webhook 请求被 API Server 接收，触发 app refresh 操作。
• 用户 CLI/UI 操作：手动执行 argocd app sync 或修改 Application 资源，API Server 将指令写入 etcd。
• ApplicationSet 控制器回调：当 ApplicationSet 生成或更新 Application 时，API Server 负责持久化。

2.2.2 Repo Server — 事件解析

Repo Server 是“配置翻译器”，负责将 Git 仓库中的原始配置转换为 Kubernetes 可理解的 Manifest：

• 仓库克隆与缓存：首次请求时克隆整个仓库，后续通过 git fetch 增量更新，避免重复拉取。
• Manifest 生成：支持 Helm Chart 渲染、Kustomize overlay 合并、纯 YAML 目录扫描。
• Revision 锁定：每次生成 Manifest 时记录 commit SHA，确保期望状态可追溯。

# Repo Server 典型调用流程（gRPC）
1. API Server 调用 GetManifests(repoURL, revision, appPath)
2. Repo Server 检查本地缓存是否命中
3. 若未命中，执行 git clone/fetch + helm template / kustomize build
4. 返回 Manifest 列表 + 依赖元数据
5. 缓存结果（TTL 默认 24h，可通过 --repo-cache-expiration 调整）

2.2.3 Application Controller — 事件执行

Application Controller 是“执行引擎”，它通过 informer 机制监听 Application 资源的变化，并驱动集群状态收敛：

• 差异计算：将 Repo Server 返回的期望状态与集群中实时资源进行 Diff。
• 同步执行：根据 Sync Policy（自动/手动）和 Sync Options（Prune、Apply Out of Sync Only）执行 kubectl apply / delete。
• 自愈循环：每 3 分钟（默认）重新比较一次，发现偏差自动纠正。

2.3 组件协作事件流（SVG 架构图）

下图展示了从 Git Push 到集群资源更新的完整事件流，以及三个组件在其中的交互位置：

2.4 组件间通信协议与端口

在生产环境中，组件间的通信安全至关重要。下表列出默认端口和协议：

2.5 组件故障对事件流的影响

在灾备场景中，组件故障会直接阻断事件流。理解每个组件失效后的影响范围，是设计高可用架构的基础：

• API Server 不可用：Webhook 无法接收，用户无法执行手动同步，但 Application Controller 仍可基于最后一次缓存的期望状态继续自愈循环。
• Repo Server 不可用：Application Controller 无法获取新的 Manifest，但已缓存的 Manifest 仍可用于差异比较。如果缓存过期，Controller 将无法执行同步。
• Application Controller 不可用：集群状态收敛完全停止，自愈和同步均无法执行，但 API Server 和 Repo Server 仍可正常处理请求。