2. Argo CD 核心架构：组件分解、数据流与状态同步机制

Argo CD 采用微服务架构，由三个核心组件协同工作：API Server、Repo Server 和 Application Controller。理解这三个组件的职责、数据流向以及状态同步机制，是诊断“存储版本漂移”和设计审计策略的基础。

2.1 核心组件分解

下表从职责、关键功能与安全关注点三个维度，对比了三个核心组件：

2.2 组件间数据流与同步机制

Argo CD 的状态同步是一个闭环反馈过程，核心数据流如下：

1. 清单生成：Repo Server 从 Git/Helm 仓库拉取源码，执行模板化渲染，生成最终的 Kubernetes 清单（YAML/JSON）。
2. 状态缓存：生成的清单被发送至 API Server，存储在 argocd-repo-server 的缓存中，并作为“期望状态”的权威来源。
3. 差异计算：Application Controller 定期（默认 3 分钟）从 API Server 获取“期望状态”，并与目标集群中资源的“实时状态”进行对比。
4. 同步执行：当检测到差异（即漂移）时，Controller 根据同步策略（手动/自动）执行 kubectl apply 或 kubectl delete 操作，使集群状态收敛于期望状态。

2.3 状态同步机制深度解析

Argo CD 的同步机制基于“期望状态”与“实时状态”的持续比较。其核心循环包含以下步骤：

• 轮询与触发：Application Controller 定期（--status-processors 参数控制）或通过 Webhook 事件触发，启动一次同步循环。
• 三向差异计算：Controller 对比三个版本的状态：期望状态（来自 Repo Server 的清单）、实时状态（来自集群 API）、已同步状态（上次成功同步的快照）。这种三向对比能精确识别漂移来源。
• 同步策略执行：根据 Application 的 syncPolicy 配置，执行自动同步或等待手动批准。同步操作包括创建、更新、删除资源。
• 健康评估：同步完成后，Controller 根据资源健康检查规则（如 Deployment 的 Available 状态）评估应用健康度。

2.4 组件交互中的关键审计点

在 Argo CD 的组件交互中，以下环节是审计“存储版本漂移”的关键切入点：

• Repo Server 的清单生成日志：记录每次从仓库拉取的 commit SHA、分支、以及生成的清单哈希值。任何与预期不符的清单变更都应在此处留下痕迹。
• API Server 的缓存更新事件：当 Repo Server 推送新清单时，API Server 会更新缓存并触发 Application Controller 的重新评估。审计此事件的时间戳和内容变更。
• Application Controller 的差异报告：Controller 会输出详细的 JSON diff，精确到每个资源的每个字段。这是检测“漂移”最直接的证据。
• 同步操作审计日志：所有 Sync、Rollback、Delete 操作都应记录操作人、时间、操作类型和结果。