3. Argo CD 核心概念：Application、Project、Repository、Sync 策略、健康检查与自动修复

在构建 Helm 应用交付集群模板蓝图时，Argo CD 的五大核心概念构成了 GitOps 工作流的骨架。理解这些概念之间的协作关系，是设计压测沙盘与容量预测模型的基础。本章将逐一剖析每个概念的定义、配置要点及在沙盘中的实际映射。

3.1 核心概念关系总览

下图展示了 Argo CD 中 Application、Project、Repository 以及 Sync/Health 机制之间的层级与数据流关系。该图也是后续压测沙盘拓扑设计的逻辑起点。

Argo CD 核心概念关系图 Argo CD Application Project Repository Sync 策略 健康检查 自动修复 (Self-Heal) 说明：Application 是核心实体，绑定 Project（权限边界）与 Repository（来源），通过 Sync 策略驱动部署，由健康检查评估状态，自动修复确保集群与 Git 一致。

3.2 Application：部署的原子单元

Application 是 Argo CD 中管理部署的最小实体，它定义了“部署什么”、“从哪里部署”、“部署到哪个集群”以及“如何同步”。在压测沙盘中，每个 Application 对应一个 Helm Chart 实例。

字段 说明 沙盘映射示例
source Git 仓库路径及 Helm Chart 路径 https://git.example.com/charts.git + path: ./nginx
destination 目标集群与命名空间 server: https://kubernetes.default.svc + namespace: sandbox-01
syncPolicy 自动同步与自动修复配置 automated: { prune: true, selfHeal: true }
revisionHistoryLimit 保留的同步历史版本数 5（压测时建议设为 2 以减少存储开销）
压测要点： 在沙盘中，Application 的数量直接影响 Argo CD 的 API Server 负载。建议使用 argocd app create 批量生成 100~500 个 Application 来模拟大规模集群场景，并观察 controller 的 Reconcile 队列深度。

3.3 Project：多租户与权限边界

Project 用于隔离 Application 的访问权限、目标集群和资源配额。在集群模板蓝图中，每个业务线或环境（如 dev/staging/prod）通常对应一个独立的 Project。

  • 源仓库白名单：限制 Application 只能从指定的 Git 仓库拉取 Helm Chart。
  • 目标集群白名单：限制 Application 只能部署到特定的 Kubernetes 集群。
  • 资源配额：限制 Project 内所有 Application 可使用的 CPU、内存总量。
  • 命名空间黑名单/白名单：控制 Application 可以部署到哪些命名空间。
# Project 配置示例
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: sandbox-project
spec:
  sourceRepos:
  - 'https://git.example.com/charts.git'
  destinations:
  - namespace: 'sandbox-*'
    server: https://kubernetes.default.svc
  clusterResourceWhitelist:
  - group: ''
    kind: Namespace
  namespaceResourceBlacklist:
  - group: 'rbac.authorization.k8s.io'
    kind: 'ClusterRoleBinding'

3.4 Repository：Chart 的单一可信源

Repository 定义了 Argo CD 如何连接 Git 仓库或 Helm Repository。对于 Helm 应用交付，推荐使用 Git 仓库作为 Chart 的单一可信源，并配合 Helm Values 文件进行环境差异化配置。

类型 连接方式 适用场景
Git 仓库 SSH / HTTPS + 需要版本控制、Code Review、多环境 Values 覆盖
Helm Repository HTTP(S) URL 使用第三方 Chart（如 Bitnami、Prometheus 社区）
本地集群 内置 OCI Registry 企业内网离线环境，Chart 打包为 OCI 镜像
沙盘建议： 压测时使用本地 Git 模拟器（如 gitea 或 gitlab 容器）来减少网络延迟干扰。每个 Repository 的 connectionState 状态应作为压测监控指标之一。

3.5 Sync 策略：从 Git 到集群的桥梁

Sync 策略决定了 Argo CD 如何将 Git 中的期望状态应用到目标集群。在压测沙盘中，不同的 Sync 策略对集群资源消耗和同步延迟有显著影响。

Sync 策略对比流程图 Git 仓库 Sync 策略决策 K8s 集群 策略选项 Manual（手动） | Automated（自动） | Automated + Prune | Automated + Self-Heal
  • Manual Sync：手动触发，适合生产环境变更审批流程。
  • Automated Sync：自动检测 Git 变更并同步，适合开发/测试环境。
  • Automated + Prune：自动同步并删除集群中 Git 中已移除的资源。
  • Automated + Self-Heal：自动同步并修复集群中的手动变更（确保集群始终与 Git 一致）。
压测风险提示： 在沙盘中启用 selfHeal 时，如果同时进行集群外的手动变更（如 kubectl edit），会触发频繁的 Reconcile 循环，导致 Argo CD Controller CPU 飙升。建议在压测期间关闭 selfHeal 或设置 syncWindow 限制同步窗口。

3.6 健康检查：应用状态的可观测性

Argo CD 通过内置的健康检查机制评估 Kubernetes 资源的状态。对于 Helm 应用，健康检查通常依赖于 Deployment、StatefulSet、Service 等资源的就绪探针。

资源类型 健康检查逻辑 常见异常状态
Deployment 检查 replicas 是否等于 readyReplicas CrashLoopBackOff、ImagePullBackOff
StatefulSet 检查所有 Pod 是否 Ready 且处于 Running 状态 Pod 启动超时、PVC 绑定失败
Service 检查 Endpoints 是否非空 Selector 不匹配、Pod 未就绪
Ingress 检查 Backend Service 是否健康 证书过期、路由规则错误
Helm Hook 等待 Job 完成（post-install/pre-upgrade） Job 失败、超时

3.7 自动修复：GitOps 的最终一致性保障

自动修复（Self-Heal）是 Argo CD 确保集群状态与 Git 仓库完全一致的核心机制。当集群中的资源被手动修改或意外删除时，Argo CD 会自动将其恢复为 Git 中定义的期望状态。

  • 触发条件：Argo CD 每 3 分钟（默认）执行一次 Reconcile，检测集群状态与 Git 的差异。
  • 修复范围：所有由 Application 管理的资源，包括 Deployment、ConfigMap、Secret 等。
  • 冲突处理：如果 Git 和集群同时发生变更，以 Git 为准（Git 是单一事实来源）。
  • 压测影响：在沙盘中，大量 Application 同时触发 Self-Heal 会导致 Controller 的 Reconcile 队列积压，建议监控 argocd_application_reconcile_info 指标。
# 启用自动修复的 Application 配置
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: nginx-sandbox
spec:
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
    - Validate=true
    - CreateNamespace=true
容量预测关联： 在压测沙盘中，自动修复的频率与 Application 数量、资源变更频率成正比。建议在容量预测模型中引入 selfHeal 启用系数（默认 1.0，关闭时为 0），用于计算 Controller 的预期 CPU 消耗。
← 上一章 📖 返回目录 下一章 →