📚 课程目录第4章 Argo CD核心概念

4. Argo CD 核心概念：Application、Project、Repository、Cluster、Sync Policy 详解

Argo CD 的架构围绕五个核心概念构建，理解它们是掌握 GitOps 实践的基础。本章将逐一剖析 Application、Project、Repository、Cluster 和 Sync Policy，并展示它们之间的协作关系。

核心关系速记： Repository 存放期望状态 → Application 定义“从哪个 Repo 的哪个路径，同步到哪个 Cluster 的哪个 Namespace” → Project 为 Application 提供安全边界和资源配额 → Sync Policy 控制同步的触发与行为。

4.1 核心概念关系总览

下图展示了五个核心概念在 Argo CD 中的逻辑关系与数据流：

4.2 Application（应用）

Application 是 Argo CD 中最重要的资源对象，它代表一个完整的部署单元。一个 Application 定义了三个关键要素：

Source（源）：指定 Kubernetes 清单所在的 Git 仓库路径、Helm Chart 或 Kustomize 目录。
Destination（目标）：指定要部署到的目标集群和命名空间。
Sync Policy（同步策略）：定义如何将源状态同步到目标集群。

Application 示例 YAML：

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: guestbook
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/argoproj/argocd-example-apps.git
    targetRevision: HEAD
    path: guestbook
  destination:
    server: https://kubernetes.default.svc
    namespace: guestbook
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

4.3 Project（项目）

Project 是 Argo CD 的逻辑分组和权限隔离单元，用于管理多个 Application 的访问边界。主要功能包括：

功能维度	说明	典型配置
源仓库限制	限制 Project 内 Application 可以引用的 Git 仓库	`sourceRepos:` 白名单列表
目标集群限制	限制可以部署到的目标集群和命名空间	`destinations:` 白名单列表
角色与权限	为不同团队或用户分配 RBAC 角色	`roles:` 自定义角色绑定
资源配额	限制 Project 内所有 Application 的资源使用上限	`namespaceResourceQuota:` 配额定义

最佳实践： 建议为每个团队或业务线创建独立的 Project，并在 Project 级别严格限制可访问的仓库和集群，避免跨团队资源误操作。

4.4 Repository（仓库）

Repository 是 Argo CD 连接 Git 仓库的凭证与配置对象。Argo CD 支持多种仓库类型：

Git 仓库：最常用，支持 HTTPS 和 SSH 认证。
Helm 仓库：直接引用 Helm Chart 仓库。
本地路径：仅用于测试场景。

仓库注册后，Argo CD 会定期轮询（默认 3 分钟）或通过 Webhook 监听变更，确保 Application 能获取最新的期望状态。

4.5 Cluster（集群）

Cluster 代表 Argo CD 可以部署应用的目标 Kubernetes 集群。集群管理要点：

集群类型	连接方式	典型用途
内嵌集群	`https://kubernetes.default.svc`	Argo CD 所在集群
外部集群	Kubeconfig 或 Bearer	开发、测试、生产集群
多集群联邦	通过 Cluster API 或手动添加	跨区域、跨环境部署

安全提示： 添加外部集群时，建议使用专用的 Service Account ，并限制其权限为最小必要范围（如只读 + 部署权限）。

4.6 Sync Policy（同步策略）

Sync Policy 定义了 Argo CD 如何将 Git 中的期望状态应用到目标集群。核心配置项如下：

策略选项	默认值	说明
automated.sync	false	启用自动同步，检测到 Git 变更后自动触发同步
automated.prune	false	自动删除集群中不再存在于 Git 中的资源
automated.selfHeal	false	自动修复集群中与 Git 状态不一致的手动变更
syncOptions	[]	附加同步选项，如 `CreateNamespace=true`、`PruneLast=true`
retry	无	失败重试策略（次数、间隔、回退因子）

同步策略的三种常见模式：

手动同步：完全由人工触发，适合生产环境严格审批流程。
自动同步（无修剪）：自动应用变更，但保留已删除资源，适合迁移过渡期。
自动同步（修剪 + 自愈）：完全自动化，集群状态始终与 Git 一致，适合成熟 GitOps 实践。

同步策略对比表：

模式	自动应用	自动删除	自动修复	推荐场景
手动	❌	❌	❌	生产环境、审批流程
自动（无修剪）	✅	❌	❌	开发环境、迁移过渡
自动（完整）	✅	✅	✅	CI/CD 流水线、测试环境

4.7 概念协作流程

下图展示了从代码提交到集群部署的完整协作流程：

4.8 实践建议

生产环境推荐配置：

为每个环境（dev/staging/prod）创建独立的 Project。
生产环境 Application 使用手动同步 + 审批流程。
开发环境启用自动同步（修剪 + 自愈）以加速迭代。
所有仓库使用 SSH 密钥或认证，避免明文凭证。
定期审计 Cluster 列表，移除不再使用的目标集群。