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

4. Argo CD 核心概念回顾：Application、Project、Sync Policy、Health Status、App of Apps 模式

在深入多租户故障域隔离演练的资源变更复核之前，必须统一团队对 Argo CD 核心概念的认知。本章将逐一拆解 Application、Project、Sync Policy、Health Status 以及 App of Apps 模式，为后续一致性校验建立共同语言。

4.1 Application：声明式应用的原子单元

Application 是 Argo CD 中最基本的资源管理单元，它将 Git 仓库中的期望清单 与 目标集群中的运行时状态 关联起来。一个 Application 定义包含三个核心部分：

Source（来源）：Git 仓库 URL、目标路径、Helm values 文件或 Kustomize 覆盖层。
Destination（目标）：目标 Kubernetes 集群的 API Server URL 以及目标命名空间。
Sync Policy（同步策略）：控制自动/手动同步、自动修剪、自我修复等行为。

关键理解： Application 不是 Helm Chart 或 Kustomize 本身，而是 Argo CD 用来管理这些清单的“控制器对象”。一个 Application 可以管理一个微服务、一个中间件组件或一个基础设施层。

4.2 Project：多租户隔离的边界

Project 是 Argo CD 中实现 租户隔离 和 资源配额 的核心抽象。每个 Application 必须属于且仅属于一个 Project。Project 通过以下维度定义隔离边界：

隔离维度	说明	典型配置示例
源仓库白名单	限制 Project 内的 Application 只能从指定的 Git 仓库拉取清单	`https://github.com/team-a/*`
目标集群/命名空间	限制资源只能部署到特定的集群或命名空间集合	`namespace: team-a-*`
资源类型白名单	允许或禁止部署特定 Kubernetes 资源类型（如禁止 ClusterRole）	`allow: Deployment, Service`
角色绑定	通过 RBAC 控制哪些用户/组可以操作该 Project 内的 Application	`role: admin, role: viewer`

故障域隔离关键点： 在多租户场景中，每个故障域（如一个可用区或一个租户集群）应映射到一个独立的 Argo CD Project。这样，Project 级别的 RBAC 和资源限制可以直接防止租户 A 的变更意外影响租户 B 的资源。

4.3 Sync Policy：变更生效的控制器

Sync Policy 决定了 Argo CD 如何将 Git 中的期望状态应用到目标集群。理解其三种核心模式对一致性复核至关重要：

Manual Sync（手动同步）：需要人工触发同步操作，适合变更审批流程严格的场景。
Automated Sync（自动同步）：Argo CD 定期检测 Git 仓库变化并自动应用，包含两个子选项：
- Prune：自动删除集群中 Git 仓库已移除的资源。
- Self-Heal：自动纠正集群中与 Git 状态不一致的手动修改。
Sync Options（同步选项）：如 Validate=false（跳过服务端校验）、PruneLast=true（先创建新资源再删除旧资源）等。

  一致性复核提示： 在故障域隔离演练后，务必检查每个 Application 的 Sync Policy 是否与演练前的基线一致。例如，演练期间可能临时关闭了 Self-Heal，演练后必须恢复。

4.4 Health Status：应用健康度的实时指标

Argo CD 为每个 Application 及其管理的资源计算 健康状态（Health Status），这是判断应用是否正常运行的关键指标。健康状态分为以下等级：

状态	颜色标识	含义	常见原因
Healthy	绿色	所有资源运行正常，符合预期	—
Progressing	蓝色	正在滚动更新或扩缩容中	Deployment 正在更新 Pod
Degraded	红色	部分或全部资源处于异常状态	Pod CrashLoopBackOff、Service 无端点
Suspended	灰色	资源被暂停（如 HPA 暂停）	手动暂停或自动缩放暂停
Missing	橙色	Git 中定义的资源在集群中不存在	资源被手动删除或从未创建
Unknown	灰色	Argo CD 无法获取健康信息	集群连接断开、CRD 未注册

健康状态由 Argo CD 内置的 资源健康检查钩子（Resource Health Checks） 计算。对于自定义资源（CRD），可以通过 resource.customizations 配置自定义健康检查逻辑。

4.5 App of Apps 模式：大规模多租户的编排范式

App of Apps 模式是 Argo CD 中用于管理 大规模多 Application 部署 的推荐架构。其核心思想是：一个“根 Application”负责管理多个“子 Application”，每个子 Application 再管理具体的 Kubernetes 资源。

App of Apps 模式在故障域隔离演练中的优势：

分层管理：根 Application 控制整体部署范围，子 Application 控制单个租户或故障域。
独立同步：演练期间可以只暂停或回滚某个子 Application，不影响其他租户。
一致性复核简化：只需对比根 Application 的 Git 状态与子 Application 的 Sync 状态，即可快速定位不一致的故障域。

  实践建议： 在 Git 仓库中，按照 apps/root.yaml → apps/tenant-a/ → apps/tenant-b/ 的目录结构组织清单。根 Application 使用 directory 类型递归扫描子 Application 的 YAML 文件。

4.6 核心概念关系总结

下表总结了五个核心概念在一致性复核中的角色与关注点：

概念	一致性复核中的角色	关键检查项
Application	复核的基本单元	Source 版本、Destination 命名空间、Sync 状态
Project	隔离边界验证	源仓库白名单、目标集群限制、RBAC 绑定
Sync Policy	变更生效规则	自动同步开关、Prune/Self-Heal 状态
Health Status	运行时健康指标	所有资源是否 Healthy、Degraded 资源原因
App of Apps	大规模编排框架	根 App 与子 App 的层级关系、递归同步状态