2. Argo CD 基础回顾：核心概念、架构组件、工作流程

在深入资源模型驱动的准入策略自动化之前，必须牢固掌握 Argo CD 的基础知识。本章将系统回顾 Argo CD 的核心概念、架构组件以及标准工作流程，为后续章节的项目级策略设计奠定坚实的理论基础。

2.1 核心概念

Argo CD 是一个基于 Kubernetes 的声明式 GitOps 持续交付工具。其核心理念是将目标环境的状态与 Git 仓库中存储的期望状态进行持续同步。以下是几个必须理解的核心概念：

概念 定义 关键作用
Application 一组 Kubernetes 资源的逻辑分组，定义了从哪个 Git 仓库获取资源以及部署到哪个目标集群/命名空间。 Argo CD 管理的基本单元，所有同步、健康检查、策略评估都围绕 Application 进行。
ApplicationSet 一个模板化的 Application 生成器，可根据参数（如 Git 目录、集群列表、PR 列表）动态生成多个 Application。 实现多集群、多环境、多租户的批量部署管理，是规模化 GitOps 的核心。
Project 用于隔离和约束 Application 的逻辑边界。定义了允许的目标集群、允许的源仓库、允许的资源类型以及同步策略。 实现多租户安全隔离和准入策略控制的核心单元，本课程的核心关注点。
Repository 存储 Kubernetes 资源清单（YAML/JSON/Helm/Kustomize）的 Git 仓库。 作为单一事实来源（Single Source of Truth），驱动所有环境的状态。
Target Cluster Argo CD 负责部署和同步的目标 Kubernetes 集群。 可以是 Argo CD 所在的集群（in-cluster）或外部集群。
Sync 将 Git 仓库中的期望状态应用到目标集群的过程。 确保集群实际状态与 Git 仓库中的声明式配置保持一致。
关键理解： Project 是 Argo CD 中实现多租户安全策略的核心。本课程后续设计的准入策略自动化，本质上就是通过编程方式动态生成和更新 Project 的约束规则，从而在 Application 创建或同步时进行拦截和校验。

2.2 架构组件

Argo CD 采用微服务架构，主要由以下几个核心组件构成，它们协同工作以实现 GitOps 工作流。

Argo CD 核心架构组件 API Server gRPC/RESTful 接口 Repo Server Git 仓库操作 Application Controller 状态监控与同步 Redis 缓存与任务队列 Dex / SSO 身份认证 Notification Controller 事件通知 组件职责说明 • API Server：处理用户/CI/CD 系统的请求，执行 RBAC 校验，管理 Application 的 CRUD。 • Repo Server：克隆 Git 仓库，生成 Helm/Kustomize 等渲染后的 Kubernetes 清单。 • Application Controller：核心控制器，持续监控 Application 状态，对比期望状态与实际状态，触发同步。 • Redis：缓存 Repo Server 生成的清单和 Application Controller 的状态，提高性能。 • Dex/SSO：集成外部身份提供商（LDAP、OIDC、GitHub 等），提供单点登录能力。 • Notification Controller：根据 Application 状态变化（如同步成功、失败）触发 Webhook、Slack、Email 等通知。

2.3 工作流程

Argo CD 的标准工作流程遵循 GitOps 的“Pull”模式，即 Argo CD 主动从 Git 仓库拉取配置并应用到集群。以下是典型的工作流步骤：

  1. 用户提交代码：开发人员将 Kubernetes 资源清单（YAML/Helm/Kustomize）推送到 Git 仓库。
  2. Argo CD 检测变更：Argo CD 的 Application Controller 定期轮询（或通过 Webhook 事件触发）Git 仓库，发现与集群当前状态存在差异。
  3. Repo Server 渲染清单：Repo Server 从 Git 仓库拉取最新代码，并根据 Application 配置（如 Helm Values、Kustomize overlay）渲染出最终的 Kubernetes 资源清单。
  4. Application Controller 执行同步：Application Controller 将渲染后的清单与集群中的实际资源进行对比，然后执行同步操作（创建、更新或删除资源）。
  5. 健康检查与状态更新：同步完成后，Application Controller 对部署的资源进行健康检查（如 Pod 是否 Running、Deployment 是否 Ready），并更新 Application 的状态（Synced、OutOfSync、Healthy、Degraded）。
  6. 通知与反馈：Notification Controller 根据状态变化发送通知，用户可通过 Argo CD UI 或 CLI 查看同步结果和资源状态。
工作流关键点： 整个流程是“声明式”的。用户只需在 Git 仓库中声明期望状态，Argo CD 负责确保集群实际状态与期望状态一致。这种模式消除了手动 kubectl apply 的操作风险，并提供了完整的审计追踪。

2.4 同步策略与安全模型

Argo CD 提供了多种同步策略，以适应不同的部署场景。同时，其安全模型通过多层机制保障集群安全。

同步策略 说明 适用场景
Manual Sync 用户手动触发同步操作，Argo CD 不会自动同步。 生产环境，需要人工审批的变更。
Auto Sync Argo CD 自动检测到 Git 仓库变更后立即执行同步。 开发/测试环境，追求快速迭代。
Self-Heal 当集群中的资源被手动修改（配置漂移）时，Argo CD 自动将其恢复为 Git 仓库中的状态。 需要严格保证集群状态与 Git 一致的环境。
Prune 同步时自动删除 Git 仓库中已不存在的资源。 清理废弃资源，保持集群整洁。
安全警告： 在生产环境中启用 Auto Sync 和 Self-Heal 需要谨慎。建议结合 Project 级别的准入策略（如禁止删除 Namespace、禁止修改关键 CRD）来降低风险。本课程后续将详细讲解如何通过资源模型自动生成这些策略。

Argo CD 的安全模型主要包含以下层次：

  • RBAC：基于角色的访问控制，控制用户对 Application、Project、Cluster 等资源的操作权限。
  • Project 约束：定义 Application 可以使用的源仓库、目标集群、允许的资源类型和命名空间。
  • 资源排除/忽略：通过配置，可以阻止 Argo CD 管理某些敏感资源（如 Secrets、ServiceAccounts）。
  • Webhook 签名：验证 Git 仓库 Webhook 请求的合法性，防止恶意触发同步。
← 上一章 📖 返回目录 下一章 →