4. 第一个应用部署:创建 Application、同步策略配置、自动同步与手动同步、观察应用状态

本章将带领你完成 Argo CD 中的第一个应用部署。你将学习如何通过 Application 资源将 Git 仓库中的 Kubernetes 清单同步到目标集群,并掌握自动同步与手动同步的区别与配置方法。这是后续所有回滚策略的基础操作。

4.1 核心概念:Application 资源

在 Argo CD 中,Application 是管理部署的核心抽象。它定义了三个关键要素:

  • Source(源):Git 仓库地址、目标路径、Helm/Kustomize 参数。
  • Destination(目标):目标集群的 API Server URL 和 Namespace。
  • Sync Policy(同步策略):决定如何以及何时将源同步到目标。
最佳实践: 始终将 Application 定义作为 YAML 文件存储在 Git 仓库中(App of Apps 模式),而非通过 UI 手动创建。这确保了所有变更可追溯、可回滚。

4.2 创建第一个 Application

以下 YAML 定义了一个名为 guestbook 的 Application,它从官方示例仓库部署一个简单的 Web 应用。

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: guestbook
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/argoproj/argocd-example-apps.git
    targetRevision: HEAD
    path: guestbook
  destination:
    server: https://kubernetes.default.svc
    namespace: guestbook
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true
关键字段说明:
  • syncPolicy.automated.prune:自动删除目标集群中不再存在于 Git 中的资源。
  • syncPolicy.automated.selfHeal:当集群状态偏离 Git 状态时,自动纠正。
  • syncOptions.CreateNamespace:如果目标 Namespace 不存在,自动创建。

使用 kubectl apply 提交该 Application 到 Argo CD:

kubectl apply -f guestbook-application.yaml

4.3 同步策略配置详解

Argo CD 提供两种同步模式,下表对比了它们的核心差异:

特性 自动同步 手动同步
触发方式 Git 仓库变更自动触发 用户通过 UI/CLI 手动触发
Prune(清理) 可配置自动执行 需手动确认
Self-Heal(自愈) 可配置自动执行 不适用
适用场景 CI/CD 流水线、频繁变更 生产环境变更审批、回滚操作
风险等级 较高(需配合回滚护栏) 较低(人工介入)
生产环境建议: 默认使用手动同步策略,仅在非生产环境或经过充分测试后启用自动同步。自动同步 + Prune + Self-Heal 的组合可能导致“配置漂移”被快速覆盖,增加故障恢复难度。

4.4 自动同步与手动同步操作

4.4.1 启用自动同步

在 Application 的 syncPolicy 中配置 automated 块即可启用。以下示例仅启用自动同步,不启用 Prune 和 Self-Heal:

syncPolicy:
  automated: {}

更保守的配置(仅同步,不删除、不自愈):

syncPolicy:
  automated:
    prune: false
    selfHeal: false

4.4.2 手动同步操作

通过 Argo CD CLI 执行手动同步:

argocd app sync guestbook --prune --apply-out-of-sync-only

参数说明:

  • --prune:允许删除目标集群中多余的资源。
  • --apply-out-of-sync-only:仅同步状态不一致的资源,提升效率。

通过 UI 手动同步:进入 Application 详情页,点击 SYNC 按钮,选择同步选项后确认。

4.5 观察应用状态

同步完成后,Argo CD 会为 Application 生成两个关键状态指标:

  • Sync Status(同步状态):Synced(一致)、OutOfSync(偏离)、Failed(失败)。
  • Health Status(健康状态):Healthy(正常)、Degraded(降级)、Progressing(进行中)、Missing(缺失)。

使用 CLI 查看状态:

argocd app get guestbook

输出示例:

Name:               guestbook
Project:            default
Server:             https://kubernetes.default.svc
Namespace:          guestbook
URL:                https://argocd.example.com/applications/guestbook
Repo:               https://github.com/argoproj/argocd-example-apps.git
Target:             HEAD
Path:               guestbook
Sync Policy:        <automated>
Sync Status:        Synced
Health Status:      Healthy
快速诊断: 如果状态显示 OutOfSync,说明集群当前状态与 Git 仓库不一致。使用 argocd app diff guestbook 查看具体差异。

4.6 同步流程可视化

下图展示了从 Git 提交到应用部署完成的完整同步链路:

Argo CD 同步流程 Argo CD 同步流程 Git 仓库 Argo CD API Server Application Controller 目标集群 用户 / CI 触发 Poll / Webhook 同步请求 kubectl apply 手动同步 说明: 自动同步由 Git 变更触发(Webhook 或轮询),手动同步由用户或 CI 系统通过 API/CLI 触发。 Application Controller 负责计算差异并执行同步操作。

4.7 状态观察与故障排查

Argo CD UI 提供丰富的可视化状态面板。以下为常见状态组合及处理建议:

Sync Status Health Status 可能原因 处理方式
Synced Healthy 一切正常 无需操作
OutOfSync Healthy 集群手动修改了资源,或 Git 有未同步的变更 执行同步或回滚集群变更
Synced Degraded Pod 崩溃、镜像拉取失败、配置错误 检查 Pod 日志和事件
OutOfSync Degraded 同步失败且应用不健康 查看同步错误详情,修复 Git 或集群问题
Failed Missing Application 定义错误或集群不可达 检查 Application YAML 和集群连接
CLI 快速排查命令:
# 查看详细状态
argocd app get guestbook -o json | jq '.status'

# 查看同步差异
argocd app diff guestbook

# 查看同步历史
argocd app history guestbook

# 查看实时事件
kubectl get events -n argocd --watch | grep guestbook

4.8 本章小结

通过本章实践,你已经掌握了:

  • 如何编写并创建 Argo CD Application 资源。
  • 自动同步与手动同步的配置差异及适用场景。
  • 使用 CLI 和 UI 执行同步操作。
  • 通过 Sync Status 和 Health Status 观察应用健康状态。