Chapter 02

Application 核心概念

深入理解 ArgoCD Application CRD 的每个字段含义,掌握手动与自动同步的区别,读懂 Sync Status 与 Health Status,并完成第一个 Application 部署。

Application CRD 概览

Application 是 ArgoCD 的核心自定义资源(CRD),它描述了一个完整的部署意图:从哪里获取配置(source),部署到哪里(destination),以及如何同步(syncPolicy)。每个 Application 对应一个由 ArgoCD 管理的应用实例。

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  namespace: argocd          # Application 资源必须在 argocd 命名空间
spec:
  project: default            # 所属 AppProject,default 为内置默认项目

  # ── Source:从哪个 Git 仓库获取配置 ──
  source:
    repoURL: https://github.com/my-org/my-app-config
    targetRevision: HEAD     # 分支/Tag/Commit SHA
    path: k8s/production      # 仓库内的目录路径

  # ── Destination:部署到哪个集群和命名空间 ──
  destination:
    server: https://kubernetes.default.svc  # 本地集群固定值
    namespace: production

  # ── SyncPolicy:如何同步 ──
  syncPolicy:
    automated:
      prune: true             # 自动删除 Git 中已移除的资源
      selfHeal: true          # 自动修复漂移
    syncOptions:
    - CreateNamespace=true   # 目标命名空间不存在时自动创建

source 字段详解

source 定义了配置的来源,ArgoCD 支持三大类 source 类型:

Git 仓库 (path)
最常见的方式。指定 Git 仓库 URL、分支/Tag/Commit(targetRevision)和目录路径(path)。ArgoCD 会递归读取该目录下所有 YAML/JSON 文件并应用。
Helm Chart
source 中添加 helm 字段,ArgoCD 将调用 Helm 渲染 Chart 后再应用。支持 Git 仓库中的 Chart(chart 字段)或 Helm Registry(repoURL 指向 OCI 或 Helm Repo)。
Kustomize
source 中添加 kustomize 字段,ArgoCD 自动检测目录下有无 kustomization.yaml,若有则调用 Kustomize build 渲染后应用。无需显式声明 kustomize 字段。
targetRevision
指定 Git 的具体版本。可以是:分支名(main、develop)、Tag(v1.2.0)、Commit SHA(abc123f)。生产环境推荐使用 Tag 而非 HEAD,确保部署的确定性。

destination 字段详解

destination 指定了部署目标,由集群 server URL 和命名空间组成:

destination:
  # 方式一:使用集群 URL(注册外部集群时的 API Server 地址)
  server: https://kubernetes.default.svc   # ArgoCD 所在集群(in-cluster)
  # 或外部集群:
  server: https://prod-cluster.example.com:6443

  # 方式二:使用集群名称(argocd cluster add 时指定的名称)
  name: production-cluster   # 与 server 二选一

  namespace: my-app           # 应用部署到的命名空间
in-cluster 的特殊写法

当 ArgoCD 部署在要管理的集群内时,destination.server 使用固定值 https://kubernetes.default.svc,这是 Kubernetes 集群内访问 API Server 的标准地址,ArgoCD 会使用 ServiceAccount token 进行认证,无需额外凭证。

手动同步 vs 自动同步

手动同步(默认)

不配置 syncPolicy.automated,Git 变更后 ArgoCD 检测到 OutOfSync 状态,但不会自动执行同步。需要手动触发:

# CLI 触发同步
argocd app sync my-app

# 或在 UI 中点击 "Sync" 按钮

自动同步(auto-sync)

配置 syncPolicy.automated,Git 有新 commit 后 ArgoCD(默认每 3 分钟轮询一次)自动触发同步:

syncPolicy:
  automated:
    prune: true
    selfHeal: true
prune
剪枝。当 Git 中某个资源被删除后,ArgoCD 是否自动将集群中对应的资源也删除。默认 false(不自动删除),生产环境按需开启,需谨慎评估。
selfHeal
自愈。当有人直接修改了集群中的资源(漂移),ArgoCD 是否自动将其恢复到 Git 定义的状态。开启后可防止手动操作意外改坏生产环境。

Sync Status 与 Health Status

ArgoCD 对每个 Application 维护两个独立的状态,理解它们的区别非常重要:

状态类型 状态值 含义
Sync Status
配置是否与 Git 一致
Synced 集群状态与 Git 中的期望状态完全一致
OutOfSync 存在差异(可能是 Git 有新 commit,或集群发生了漂移)
Unknown 无法获取状态(如无法连接目标集群)
Health Status
应用是否健康运行
Healthy 所有资源健康(Pod Running、Deployment 副本就绪)
Progressing 资源正在部署中(Deployment 滚动更新未完成)
Degraded 有资源处于异常状态(Pod CrashLoopBackOff 等)
Suspended 资源被暂停(如 CronJob 暂停)
Unknown ArgoCD 没有该资源类型的健康检查规则
两个状态独立变化

Sync Status 和 Health Status 是独立的:一个应用可能是 Synced + Degraded(配置已同步,但 Pod 在 CrashLoop);也可能是 OutOfSync + Healthy(有人手动改了配置,但应用仍然正常运行)。部署时两个状态都需要关注。

syncOptions 常用选项

syncPolicy:
  syncOptions:
  - CreateNamespace=true         # 自动创建目标 namespace
  - PruneLast=true               # 先创建新资源,最后再删除旧资源
  - ApplyOutOfSyncOnly=true      # 只 apply 有差异的资源(提升性能)
  - ServerSideApply=true         # 使用 Server-Side Apply(推荐)
  - FailOnSharedResource=true    # 多个 App 管理同一资源时报错
  - RespectIgnoreDifferences=true # 同步时遵守 ignoreDifferences 规则

实战:部署第一个 Application

用一个简单的 nginx Deployment 演示完整流程:

  1. 在 GitHub 创建配置仓库 my-gitops-config,目录结构如下:
    my-gitops-config/
    └── nginx/
        ├── deployment.yaml
        └── service.yaml
  2. 编写 Kubernetes 清单文件:
    # deployment.yaml
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: nginx
      namespace: demo
    spec:
      replicas: 2
      selector:
        matchLabels:
          app: nginx
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
          - name: nginx
            image: nginx:1.25
            ports:
            - containerPort: 80
  3. 创建 ArgoCD Application(推荐通过 YAML 声明式创建):
    # argocd-app-nginx.yaml
    apiVersion: argoproj.io/v1alpha1
    kind: Application
    metadata:
      name: nginx-demo
      namespace: argocd
      finalizers:
      - resources-finalizer.argocd.argoproj.io   # 删除 App 时级联删除 K8s 资源
    spec:
      project: default
      source:
        repoURL: https://github.com/my-org/my-gitops-config
        targetRevision: HEAD
        path: nginx
      destination:
        server: https://kubernetes.default.svc
        namespace: demo
      syncPolicy:
        automated:
          prune: true
          selfHeal: true
        syncOptions:
        - CreateNamespace=true
  4. 提交 Application 到集群:
    kubectl apply -f argocd-app-nginx.yaml
    
    # 观察同步状态
    argocd app get nginx-demo
    argocd app wait nginx-demo --health
  5. 验证应用已部署:
    kubectl get pods -n demo
    # NAME                     READY   STATUS    RESTARTS
    # nginx-xxx-yyy            1/1     Running   0
    # nginx-xxx-zzz            1/1     Running   0
避免在 Git 仓库中存放 Application CRD

很多团队会将 Application YAML 也存入 Git 仓库,通过"App of Apps"模式管理。但注意:Application YAML 应提交到一个专门的"根 Application"仓库,而非应用本身的配置仓库,避免循环依赖。

本章小结

Application CRD 通过 source(Git 仓库来源)、destination(部署目标集群/命名空间)、syncPolicy(同步策略)三部分定义完整的部署意图。自动同步中 prune 控制删除、selfHeal 控制漂移修复。Sync Status(配置一致性)与 Health Status(运行状态)是两个独立维度,都需要关注。