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

2. Argo CD 核心概念回顾

在深入可观测性平台配置管理之前，必须统一对 Argo CD 核心概念的理解。这些概念构成了所有后续工程实践的基础，包括 Application、Project、Repository、Sync 策略、Health 状态以及 App of Apps 模式。本章将逐一回顾这些概念，并建立它们之间的关联。

2.1 Application：最小部署单元

Application 是 Argo CD 中管理 GitOps 工作负载的最小单元。它定义了一个 Kubernetes 资源集合的期望状态、来源仓库以及目标集群/命名空间。

字段	说明	示例值
source	Git 仓库地址、路径、分支及 Helm/Kustomize 参数	`https://github.com/org/observability.git`
destination	目标集群 URL 和命名空间	`https://kubernetes.default.svc / monitoring`
syncPolicy	自动同步、自愈、Prune 等行为控制	`automated: { prune: true }`

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: prometheus-stack
  namespace: argocd
spec:
  project: observability
  source:
    repoURL: https://github.com/org/observability-config.git
    targetRevision: main
    path: prometheus-stack
  destination:
    server: https://kubernetes.default.svc
    namespace: monitoring
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

实践要点：每个可观测性组件（Prometheus、Grafana、Loki、Tempo）应独立为一个 Application，便于独立回滚和版本控制。

2.2 Project：多租户隔离边界

Project 是 Argo CD 中的逻辑分组和权限隔离单元。它约束了哪些 Application 可以部署到哪些目标集群和命名空间，以及允许访问哪些 Git 仓库。

源仓库约束：只允许从白名单内的仓库拉取配置
目标集群约束：限制可部署的 Kubernetes 集群和命名空间
资源配额：限制集群资源使用量（CPU、内存、存储）
角色绑定：与 RBAC 结合，控制团队访问权限

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: observability
  namespace: argocd
spec:
  sourceRepos:
    - 'https://github.com/org/observability-config.git'
  destinations:
    - namespace: monitoring
      server: https://kubernetes.default.svc
    - namespace: logging
      server: https://kubernetes.default.svc
  clusterResourceWhitelist:
    - group: ''
      kind: Namespace

2.3 Repository：配置来源管理

Repository 定义了 Argo CD 可以访问的 Git 仓库凭证和连接信息。支持公开仓库和私有仓库（通过 SSH 密钥或 HTTPS 认证）。

认证方式	适用场景	安全建议
SSH 密钥	私有仓库，长期稳定	使用专用部署密钥，限制只读权限
HTTPS	CI/CD 集成，短期凭证	使用 Argo CD 的 `argocd repo add` 加密存储
公开仓库	公开 Helm Chart 或示例配置	无需凭证，但需注意供应链安全

安全警告：可观测性配置常包含告警规则、仪表板 JSON 和采集端点信息。务必使用私有仓库并限制访问权限，避免敏感信息泄露。

2.4 Sync 策略：配置交付模式

Sync 策略决定了 Argo CD 如何将 Git 仓库中的期望状态应用到目标集群。理解不同策略的适用场景，是管理可观测性平台配置的关键。

策略	行为	可观测性场景
手动同步	需人工触发 sync 操作	重大变更前的审核阶段
自动同步	检测到 Git 变更后自动部署	日常告警规则、仪表板更新
自愈 (Self-Heal)	集群状态偏离 Git 时自动纠正	防止手动修改采集器配置
Prune	删除 Git 中已移除的资源	清理废弃的 ServiceMonitor

syncPolicy:
  automated:
    prune: true          # 自动删除已移除的资源
    selfHeal: true       # 自动修复集群偏离
  syncOptions:
    - CreateNamespace=true  # 自动创建目标命名空间

2.5 Health 状态：部署健康度评估

Argo CD 通过内置的 Health 检查机制评估每个资源的状态。对于可观测性平台，健康状态直接反映了监控基础设施的可用性。

  关键指标：可观测性平台自身的 Application Health 状态应作为平台可用性的核心 SLO。建议设置 Prometheus 告警规则监控 Argo CD Application 的 Health 状态变化。

2.6 App of Apps 模式：大规模配置编排

App of Apps 模式是管理大量 Application 的推荐方式。它通过一个根 Application 来管理多个子 Application，实现配置的层次化编排。

# 根 Application 示例：observability-root.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: observability-root
  namespace: argocd
spec:
  project: observability
  source:
    repoURL: https://github.com/org/observability-config.git
    targetRevision: main
    path: apps
  destination:
    server: https://kubernetes.default.svc
    namespace: argocd
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

工程实践：在可观测性平台中，建议将每个数据源（Prometheus、Loki、Tempo）和每个可视化组件（Grafana）都定义为独立的子 Application。这样可以在不中断其他组件的情况下，单独升级或回滚某个数据源。

2.7 核心概念关系总结

概念	在可观测性平台中的角色	管理要点
Application	每个可观测性组件对应一个 Application	独立版本控制，独立回滚
Project	隔离不同环境（prod/staging）的配置	限制目标命名空间和仓库
Repository	存储告警规则、仪表板 JSON、采集配置	使用私有仓库，配置 Webhook
Sync 策略	自动同步告警规则变更，手动同步重大升级	生产环境启用 selfHeal 防止配置漂移
Health 状态	反映可观测性基础设施的健康度	集成到告警系统，触发 PagerDuty/钉钉
App of Apps	编排整个可观测性技术栈的部署	根 Application 只管理子 Application 声明

  核心原则：可观测性平台的配置管理应遵循 GitOps 的声明式哲学——所有配置变更必须通过 Git 提交触发，Argo CD 自动将期望状态同步到集群。任何手动修改都应被视为配置漂移，并通过自愈机制自动纠正。