Argo CD 基础回顾：架构、核心组件与工作流程
在深入镜像安全与准入控制集成之前，必须先牢固掌握 Argo CD 的基础架构。Argo CD 是一个基于 Kubernetes 的声明式 GitOps 工具，其核心思想是将 Git 仓库作为应用状态和配置的“唯一事实来源”。理解其架构、组件和工作流程，是后续排查镜像扫描失败、策略拒绝等故障的前提。
Argo CD 整体架构
Argo CD 采用微服务架构，主要由三个核心组件构成：API Server、Repo Server 和 Application Controller。这三个组件协同工作，实现了从 Git 仓库到 Kubernetes 集群的持续同步。
核心组件详解
每个组件承担明确的职责，理解其边界有助于快速定位故障点。
| 组件 | 职责 | 关键接口 | 故障排查关注点 |
|---|---|---|---|
| API Server | 对外暴露 gRPC/REST API，处理用户认证、授权、应用 CRUD 操作，以及 Webhook 触发。 | gRPC (CLI/UI)、REST (Webhook) | 过期、RBAC 配置错误、Webhook 超时 |
| Repo Server | 克隆 Git 仓库、生成 Kubernetes 清单（Helm/Kustomize/Jsonnet），并缓存结果。 | 与 Git 仓库通信、内部 gRPC | Git 凭证失效、仓库访问超时、Helm 依赖下载失败 |
| Application Controller | 持续对比 Git 中声明的期望状态与集群中实际状态，执行同步操作。 | Kubernetes API | 集群权限不足、资源冲突、同步策略死循环 |
🔍 镜像安全视角： 当准入控制拒绝一个镜像时，故障通常发生在 Application Controller 尝试创建 Pod 的阶段。此时需要检查 Controller 的日志以及准入 Webhook 的响应。
工作流程：从 Git 提交到集群同步
Argo CD 的完整工作流程可以概括为以下 6 个步骤。理解这个流程，是后续配置镜像扫描准入控制的基础。
- 用户提交变更：开发者将应用清单（Deployment、Service 等）推送到 Git 仓库。
- Repo Server 拉取：Argo CD 的 Repo Server 定期或通过 Webhook 触发，克隆仓库并渲染最终的 Kubernetes 清单。
- API Server 存储期望状态：渲染后的清单被发送回 API Server，作为“期望状态”存储在 Argo CD 的内部存储（CRD）中。
- Application Controller 对比：Controller 持续对比“期望状态”与集群中的“实际状态”。
- 检测偏差：如果发现偏差（OutOfSync），Controller 标记应用状态为“不同步”。
- 执行同步：根据同步策略（自动或手动），Controller 调用 Kubernetes API 创建/更新/删除资源，使集群状态与 Git 一致。
同步策略与镜像安全的关系
Argo CD 支持两种同步模式，它们对镜像安全故障的影响截然不同：
- 手动同步：由运维人员点击“Sync”按钮触发。适合需要人工审核镜像扫描结果的场景。
- 自动同步：Git 仓库一有变更，立即自动同步。如果镜像准入控制拒绝，会导致应用持续处于
OutOfSync状态，并产生大量告警。
⚠️ 常见故障场景： 在自动同步模式下，如果准入控制拒绝了一个包含高危漏洞镜像的 Deployment，Argo CD 会不断尝试同步，导致 Application Controller 日志中出现大量
Failed to sync 错误。排查时，应首先检查 Controller 日志中的 admission webhook 相关拒绝信息。
关键 CRD 回顾
Argo CD 通过自定义资源定义（CRD）来管理应用。以下两个 CRD 与镜像安全排查直接相关：
| CRD 名称 | 用途 | 镜像安全相关字段 |
|---|---|---|
Application |
定义应用来源（Git 仓库路径）和目标集群。 | spec.source.helm.values（可能包含镜像标签） |
AppProject |
定义应用所属项目，用于 RBAC 和资源限制。 | spec.sourceRepos（限制允许的 Git 仓库） |