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

2. Argo CD 核心概念回顾：Application、Project、Sync Policy、Health Status、Drift Detection 基础

在深入多集群版本漂移检测之前，必须统一对 Argo CD 核心概念的理解。这些概念是后续所有检测策略、自动化修复和策略引擎的基础。本章将围绕五个关键领域展开：Application（应用）、Project（项目）、Sync Policy（同步策略）、Health Status（健康状态）以及 Drift Detection（漂移检测）的基本原理。

2.1 Application：Argo CD 的核心工作单元

Application 是 Argo CD 中管理部署的最小单元，它定义了一个 Kubernetes 应用从 Git 仓库到目标集群的完整映射关系。一个 Application 包含以下关键字段：

字段	说明	示例值
source	Git 仓库地址、目标路径、Helm/Kustomize 参数	`https://github.com/example/app.git`
destination	目标集群 URL 和命名空间	`https://k8s-cluster-1:6443` / `production`
syncPolicy	自动同步、自愈、Prune 等行为配置	`automated: { prune: true }`
revisionHistoryLimit	保留的同步历史记录数	`10`

关键理解：Application 是“声明式期望”的载体。Argo CD 持续对比 source 中的清单与 destination 集群中的实际资源，任何差异都被视为“漂移”。

2.2 Project：多租户与访问控制边界

Project 是 Argo CD 中用于隔离 Application 和资源的逻辑分组。它定义了哪些 Git 仓库、目标集群、命名空间和资源类型可以被该 Project 下的 Application 使用。Project 是实施多集群、多团队治理的核心工具。

源仓库白名单：限制 Application 只能从授权的 Git 仓库拉取清单。
目标集群白名单：限制 Application 只能部署到指定的集群和命名空间。
资源类型限制：控制允许创建的 Kubernetes 资源类型（如禁止创建 ClusterRole）。
Sync 窗口：定义允许或禁止同步的时间段，用于生产环境变更管控。

漂移检测视角：Project 级别的限制不会阻止漂移的发生，但可以控制哪些 Application 可以被自动修复。在多集群场景中，建议为每个集群或环境创建独立的 Project，以便精细控制自愈策略。

2.3 Sync Policy：同步行为与自愈机制

Sync Policy 决定了 Argo CD 如何处理 Git 与集群之间的差异。它直接影响漂移检测后的响应动作。

策略类型	子选项	行为描述	漂移检测影响
Manual	—	仅手动触发同步，不自动修复	漂移会被检测但不会自动纠正
Automated	`prune: false`	自动同步，但保留集群中多余资源	漂移部分修复，残留资源可能引发二次漂移
Automated	`prune: true`	自动同步并删除集群中多余资源	完全自愈，但需谨慎使用
Automated	`selfHeal: true`	检测到漂移后立即自动同步	实时漂移修复，适合生产环境

  实战建议：在多集群版本漂移检测场景中，建议为关键业务 Application 开启 automated.sync 和 automated.selfHeal，但将 prune 设置为 false 并配合人工审批流程，避免误删资源。

2.4 Health Status：应用健康状态评估

Health Status 是 Argo CD 对 Application 当前运行状况的评估，它独立于 Sync Status。一个 Application 可能处于“已同步”状态但“不健康”。健康状态由 Argo CD 内置的 Liveness 探针或自定义健康检查脚本决定。

# 常见的健康状态枚举
# Healthy   — 所有资源正常运行，Pod 就绪，Service 有端点
# Progressing — 正在滚动更新或扩缩容
# Degraded  — 部分资源失败，如 CrashLoopBackOff
# Suspended — 资源被暂停（如 HPA 暂停）
# Missing   — 期望的资源在集群中不存在
# Unknown   — 无法评估健康状态

健康状态与漂移检测的关系：漂移不一定会导致不健康。例如，手动修改 Deployment 的 replicas 从 3 到 5，Argo CD 会检测到漂移，但如果 Pod 正常运行，健康状态仍为 Healthy。反之，不健康也不一定由漂移引起，可能是镜像拉取失败或资源不足。

漂移检测策略：在构建多集群检测系统时，应同时监控 Sync Status 和 Health Status。仅当两者同时异常时，才触发高级告警或自动回滚。

2.5 Drift Detection 基础：Argo CD 如何发现漂移

Drift Detection（漂移检测）是 Argo CD 的核心能力。它通过持续对比“期望状态”（Git 仓库中的清单）与“实际状态”（Kubernetes 集群中的实时资源）来发现差异。检测机制基于以下流程：

定期轮询：Argo CD 每隔 --status-processors 配置的时间（默认 3 分钟）对所有 Application 执行一次状态对比。
Webhook 触发：Git 仓库或集群事件可触发即时对比，减少检测延迟。
差异计算：Argo CD 将 Git 中的 YAML 渲染为期望的 Kubernetes 对象，然后与集群中的实际对象进行深度比较（忽略 metadata.generation、status 等自动生成字段）。
结果分类：差异被归类为 OutOfSync（漂移）、Synced（一致）或 Unknown（无法比较）。

  漂移检测的粒度：Argo CD 支持按资源级别检测漂移。例如，一个 Deployment 的 spec.replicas 从 3 变为 5，Argo CD 会精确指出哪个字段发生了漂移，并显示期望值和实际值。

2.6 核心概念关系总结

下表总结了五个核心概念在漂移检测场景中的角色与相互作用：

概念	漂移检测中的角色	与多集群的关系
Application	定义漂移检测的范围（源 + 目标）	每个集群对应一个 Application 实例
Project	控制哪些 Application 可以被检测和修复	按集群或环境隔离 Project
Sync Policy	决定检测到漂移后的响应动作	不同集群可配置不同策略
Health Status	评估漂移是否影响应用运行	跨集群健康状态聚合分析
Drift Detection	核心检测机制，输出差异报告	多集群统一检测与告警

常见误区：不要将 Sync Status 等同于 Health Status。一个 Application 可能处于 OutOfSync 但 Healthy（例如手动扩缩容），也可能处于 Synced 但 Degraded（例如镜像拉取失败）。在多集群漂移检测中，必须同时关注这两个维度。