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 提交到应用部署完成的完整同步链路:
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 观察应用健康状态。