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 类型:
helm 字段,ArgoCD 将调用 Helm 渲染 Chart 后再应用。支持 Git 仓库中的 Chart(chart 字段)或 Helm Registry(repoURL 指向 OCI 或 Helm Repo)。kustomize 字段,ArgoCD 自动检测目录下有无 kustomization.yaml,若有则调用 Kustomize build 渲染后应用。无需显式声明 kustomize 字段。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 # 应用部署到的命名空间
当 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
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 演示完整流程:
- 在 GitHub 创建配置仓库
my-gitops-config,目录结构如下:my-gitops-config/ └── nginx/ ├── deployment.yaml └── service.yaml - 编写 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 - 创建 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 - 提交 Application 到集群:
kubectl apply -f argocd-app-nginx.yaml # 观察同步状态 argocd app get nginx-demo argocd app wait nginx-demo --health - 验证应用已部署:
kubectl get pods -n demo # NAME READY STATUS RESTARTS # nginx-xxx-yyy 1/1 Running 0 # nginx-xxx-zzz 1/1 Running 0
很多团队会将 Application YAML 也存入 Git 仓库,通过"App of Apps"模式管理。但注意:Application YAML 应提交到一个专门的"根 Application"仓库,而非应用本身的配置仓库,避免循环依赖。
Application CRD 通过 source(Git 仓库来源)、destination(部署目标集群/命名空间)、syncPolicy(同步策略)三部分定义完整的部署意图。自动同步中 prune 控制删除、selfHeal 控制漂移修复。Sync Status(配置一致性)与 Health Status(运行状态)是两个独立维度,都需要关注。