2. Argo CD 基础回顾:核心概念

在深入容量规划与多集群资源分配之前,必须牢固掌握 Argo CD 的四个核心抽象:Application、Project、Repository 和 Cluster。这四个概念构成了 Argo CD 声明式 GitOps 的基石,也是后续所有容量规划策略的操作对象。

2.1 核心概念总览

下表从定义、作用域、典型用途三个维度对比了四个核心概念,帮助你快速建立整体认知。

概念 定义 作用域 典型用途
Application 一组 Kubernetes 资源的声明式定义,包含来源(Repo + Path)与目标(Cluster + Namespace) 命名空间级 / 集群级 部署微服务、数据库、监控组件
Project Application 的逻辑分组与权限边界,控制可访问的 Repo、Cluster、Namespace 和资源 Argo CD 实例级 多租户隔离、环境划分(dev/staging/prod)
Repository 存储 Kubernetes 清单或 Helm/Kustomize 配置的 Git 仓库 全局 应用源码、基础设施即代码、配置模板
Cluster Argo CD 可以部署应用的目标 Kubernetes 集群 全局 生产集群、staging 集群、边缘集群
容量规划视角: 在后续章节中,Application 是资源消耗的最小计量单元,Project 是配额管理的边界,Cluster 是容量池,Repository 是配置变更的源头。理解这四个概念的关系,是设计多集群资源分配策略的前提。

2.2 Application(应用)

Application 是 Argo CD 中最核心的资源对象。它定义了一个“从 Git 仓库的某个路径同步到目标集群的某个命名空间”的完整部署单元。每个 Application 包含三个关键部分:

  • Source(来源):指定 Git 仓库 URL、目标分支、路径以及配置管理工具(Helm、Kustomize、纯 YAML)。
  • Destination(目标):指定目标集群的 API Server URL 或集群名称,以及目标命名空间。
  • Sync Policy(同步策略):定义自动同步、自动修剪、自动自愈等行为。
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: payment-service
  namespace: argocd
spec:
  project: production
  source:
    repoURL: 'https://git.company.com/backend/payment.git'
    targetRevision: main
    path: deploy/overlays/production
  destination:
    server: 'https://kubernetes.default.svc'
    namespace: payment
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
容量规划要点: 每个 Application 的 spec.source 决定了配置的版本与内容,而 spec.destination 决定了资源被部署到哪个集群。在规划多集群容量时,需要为每个 Application 标注预期的资源请求(CPU/Memory),以便后续进行聚合分析。

2.3 Project(项目)

Project 是 Argo CD 中的租户隔离单元。它定义了哪些 Repository、Cluster 和 Namespace 可以被该 Project 下的 Application 使用。Project 还支持设置资源配额(Resource Quotas)和全局策略。

一个典型的 Project 配置包含以下约束:

  • sourceRepos:允许引用的 Git 仓库列表。
  • destinations:允许部署的目标集群和命名空间组合。
  • clusterResourceWhitelist / Blacklist:允许或禁止的集群级资源类型。
  • namespaceResourceWhitelist / Blacklist:允许或禁止的命名空间级资源类型。
  • orphanedResources:是否监控并处理孤儿资源。
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: production
  namespace: argocd
spec:
  sourceRepos:
    - 'https://git.company.com/backend/*'
    - 'https://git.company.com/infra/*'
  destinations:
    - namespace: 'payment'
      server: 'https://kubernetes.default.svc'
    - namespace: 'inventory'
      server: 'https://prod-cluster-2.example.com'
  clusterResourceWhitelist:
    - group: ''
      kind: Namespace
  namespaceResourceBlacklist:
    - group: 'rbac.authorization.k8s.io'
      kind: RoleBinding
容量规划关键: Project 的 destinations 字段直接决定了哪些 Application 可以部署到哪些集群。在容量规划中,可以通过 Project 来划分业务线或环境,并为每个 Project 设置全局资源配额上限,防止单个 Project 耗尽集群资源。

2.4 Repository(仓库)

Repository 是 Argo CD 连接 Git 仓库的凭证与配置对象。Argo CD 支持公开仓库和私有仓库(通过 SSH 密钥、HTTPS 用户名密码或 GitHub App 认证)。

Repository 的配置包括:

  • URL:Git 仓库地址。
  • 类型:git 或 helm。
  • 认证信息:sshPrivateKey、password、tlsClientCertData 等。
  • 代理设置:proxy、insecure 等。
apiVersion: v1
kind: Secret
metadata:
  name: repo-backend
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: repository
stringData:
  type: git
  url: https://git.company.com/backend/payment.git
  username: git-robot
  password: ${GIT_}
容量规划关联: Repository 本身不直接消耗集群计算资源,但它是配置变更的源头。在容量规划中,需要关注 Repository 的 分支数量 和 提交频率,因为 Argo CD 需要定期轮询或通过 Webhook 触发重新同步,这会消耗 Argo CD 自身的计算资源(CPU/Memory)。高频变更的仓库需要更高的 Argo CD 实例规格。

2.5 Cluster(集群)

Cluster 对象定义了 Argo CD 可以管理的外部 Kubernetes 集群。Argo CD 通过 kubeconfig 或 Service Account 连接到目标集群,并在目标集群上安装一个 argocd-manager ServiceAccount 来执行部署操作。

Cluster 配置的关键字段:

  • server:目标集群的 API Server URL。
  • name:集群别名,用于在 Application 中引用。
  • config:认证信息(bearerToken、tlsClientConfig 等)。
  • namespaces:可选,限制 Argo CD 可以操作的命名空间列表。
apiVersion: v1
kind: Secret
metadata:
  name: cluster-prod-1
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: cluster
stringData:
  name: prod-1
  server: https://prod-cluster-1.example.com:6443
  config: |
    {
      "bearerToken": "<service-account->",
      "tlsClientConfig": {
        "insecure": false,
        "caData": "<base64-ca-cert>"
      }
    }

2.6 核心概念关系图

下图展示了四个核心概念之间的逻辑关系与数据流向:

Argo CD 核心概念关系图 Argo CD 核心概念关系 Repository Git 仓库 / Helm Chart Project 权限 & 配额边界 Application 部署单元 Cluster 目标 Kubernetes 集群 source project 引用 destination 容量规划关键路径 1. Repository 提供配置版本 → 2. Project 约束部署范围与配额 3. Application 声明资源需求 → 4. Cluster 提供实际容量 容量规划 = 聚合所有 Application 的资源请求,按 Project 和 Cluster 维度进行分配与限制

2.7 多集群部署中的概念映射

在容量规划驱动的多集群场景中,这四个概念会形成以下映射关系:

概念 单集群场景 多集群场景 容量规划影响
Application 一个 Application 对应一个服务 一个 Application 可部署到多个集群(通过 ApplicationSet) 需要按集群维度统计副本数与资源请求
Project 按环境划分(dev/staging/prod) 按业务线 + 区域划分(payment-asia/payment-eu) 每个 Project 需要独立的资源配额上限
Repository 一个仓库对应一个应用 多仓库按团队或服务拆分 仓库数量影响 Argo CD 轮询负载
Cluster 一个集群承载所有应用 多个集群按区域、环境、业务线分布 每个集群需要独立的容量监控与预留
实践建议: 在开始容量规划之前,建议先梳理现有 Argo CD 中的 Application、Project、Repository 和 Cluster 清单。使用 argocd app list、argocd proj list、argocd repo list 和 argocd cluster list 命令导出当前状态,作为容量基线数据。