• 文档
• 教程
• DevOps
• 运维

导读

本文基于 devops-exercises 仓库中 sync_app_cluster 练习，完整讲解 ArgoCD 的"集群侧状态漂移（drift）检测与手动同步"工作流：当集群内的应用被kubectl等命令直接改动后，ArgoCD 如何发现实际状态与 Git 期望状态不一致、将其标记为 out-of-sync，并最终通过 UI 或 CLI 恢复到期望状态。读完本文，你将掌握argocd app get、argocd app sync、argocd app wait等核心命令的实战用法，理解 GitOps 中"单一事实来源（Single Source of Truth）"为何能约束人工变更。

练习背景：为什么要"从集群侧"破坏同步

在 GitOps 模式下，ArgoCD 会周期性地（默认每 3 分钟一次）对比 Git 仓库中的期望状态与 Kubernetes 集群中的实际状态，并据此给出应用的同步状态：

• 状态一致 → 应用标记为Synced（已同步）；
• 状态不一致 → 应用标记为OutOfSync（偏离同步），随后是否纠正取决于同步策略（自动或手动）。

仓库的 ArgoCD 问答部分 专门描述了这个过程："Gathers list of all the apps to sync，获取每个仓库的 Git 状态，再对 Git 状态与集群状态做比较"。本练习（Sync App - Cluster）与同目录的 Sync App - Git 正好互为镜像：

• Git 侧练习：改动仓库里的 Kubernetes 清单，观察 ArgoCD 检测到"期望状态更新"；
• 集群侧练习（本文）：不改 Git，直接用kubectl改动集群里的资源，制造"实际状态偏离期望状态"。

两种场景最终都指向同一个动作——把集群拉回 Git 定义的期望状态，这正是 GitOps 的核心价值：无论偏差来自哪里（代码更新还是人工误操作），最终都以 Git 为准。

前置要求

开始练习前，需要满足以下两个条件（原文要求）：

1. 运行中的 Kubernetes 集群，且已安装 ArgoCD：ArgoCD 以 Kubernetes 原生方式运行在集群中，作为控制器监控状态差异。
2. 一个已被 ArgoCD 跟踪（tracked）的应用：即已创建过 ArgoCD Application 资源，Git 仓库中的清单已成功同步到集群。如果还没有应用，可先完成仓库中的 App Creation 练习（创建app-demo并同步）或 Sync App - Git 练习（用 CLI/UI 创建指向 Kubernetes 清单仓库的 Application）。

关于 Application：它是 ArgoCD 的核心自定义资源（CRD），负责把应用资源部署并同步到 Kubernetes 集群。一个 Application 通过source字段（repoURL、targetRevision、path）声明从哪个 Git 仓库读取期望状态，通过destination字段（server、namespace）声明同步到哪个集群和命名空间——相关字段说明可参考 ArgoCD 问答 中的 Practical ArgoCD 101 小节。

练习目标

原文定义了四个递进式目标：

1. 验证应用已被 ArgoCD 跟踪，且当前处于 in-sync 状态；
2. 通过一条kubectl命令对应用做出任意改动（改动内容可以很"极端"）；
3. 回到 ArgoCD 检查应用状态，确认其已变为 out-of-sync；
4. 手动执行 Sync，把集群状态恢复为 Git 期望状态。

制造漂移：用 kubectl 改动集群状态

原练习建议的改动方式任选其一，越"极端"越能直观体会漂移检测：

• 修改镜像 tag：kubectl set image deployment/<DEPLOYMENT_NAME> <CONTAINER_NAME>=<new-image:tag>；
• 修改副本数：kubectl scale --replicas=0 <DEPLOYMENT_NAME>（官方解法采用的就是这条）；
• 直接删除资源：kubectl delete deployment <DEPLOYMENT_NAME>。

只要改动后实际状态不再等于 Git 中清单声明的状态，ArgoCD 在下一个同步周期（默认 3 分钟，可用timeout.reconciliation配置调整）就会把应用标记为 OutOfSync。需要注意：这里演示的是手动同步策略下 ArgoCD 的表现——它只负责"识别差异"而不主动纠正（关于手动 vs 自动同步的机制，见 ArgoCD Syncs 问答）。

解法 A：通过 ArgoCD UI 观察并同步

第一步：确认初始健康状态

在 ArgoCD UI 中点击应用，确认其处于Synced与Healthy状态。"Healthy" 表示应用的健康评估通过（对 Deployment/ReplicaSet 等而言，即期望状态与实际状态一致，包括副本数）。

第二步：在集群中制造变更

在终端执行：

kubectl scale --replicas=0 <DEPLOYMENT_NAME> kubectl get rs <DEPLOYMENT_NAME>

第一条命令把副本数缩为 0，制造与清单（如声明 replicas: 3）的差异；第二条命令查看 ReplicaSet 当前状态，作为改动生效的佐证。

第三步：回到 UI 检查状态

刷新应用页面（若显示仍为 Synced，点击Refresh强制重新对比）：

• 应用应变为OutOfSync状态；
• 如需进一步确认差异细节，可参考 Git 侧练习的App diff功能查看具体变更内容。

第四步：执行同步

点击Sync按钮，再点击Synchronize，ArgoCD 会把集群实际状态拉回 Git 期望状态（即恢复replicas: 3）。

解法 B：通过 ArgoCD CLI 观察并同步

官方解法给出了一条完整的 CLI 命令链，可直接在终端按序执行：

# 1. 检查应用状态，确认当前 in-sync argocd app get app-demo # 2. 用 kubectl 改动集群状态（或任何其他会改变应用状态的命令） kubectl scale --replicas=0 <DEPLOYMENT_NAME> kubectl get rs <DEPLOYMENT_NAME> # 3. 再次检查应用状态，此时应为 out-of-sync argocd app get app-demo # 4. 同步应用状态，并等待同步完成 argocd app sync app-demo argocd app wait app-demo

命令逐个拆解：

• argocd app get app-demo：输出应用详情，包括同步状态（Synced/OutOfSync）、健康状态（Healthy/Degraded/Progressing 等）、目标集群与命名空间。执行两次即可直观看到状态从 Synced 变为 OutOfSync；
• argocd app sync app-demo：手动触发一次同步，把 Git 期望状态应用到集群；
• argocd app wait app-demo：阻塞等待应用达到同步与健康状态，适合在脚本中做串行化控制（同步后立即等待结果，成功才继续后续步骤）。

若使用 Git 侧 sync_app_git 练习 创建的应用，应用名同样是app-demo，可无缝套用以上命令。

原理纵深：ArgoCD 为什么能"纠正"人工改动

练习背后隐藏着一个关键机制：ArgoCD 检测到状态偏离后，会从 GitOps 仓库同步，覆盖掉人工改动。这在仓库 ArgoCD 问答 中有明确描述："一旦某工程师手工修改了集群、覆盖了仓库中的部分配置，ArgoCD 会检测到状态分歧并从 GitOps 仓库同步，覆盖掉人工修改"。

这带来两个延伸结论：

1. 单一事实来源：Git 仓库是唯一允许改动集群的入口。即使有人手动kubectl覆盖，也只会被 ArgoCD 拉回，无法长期生效；
2. 可配置的纠偏行为：如果你希望 ArgoCD 不自动覆盖人工变更，而是改为告警等动作，可以通过配置实现（对应问答中 Nate 的问题场景）。这也是自愈（Self-Heal）概念的边界——自动纠正集群状态使其匹配期望状态。

健康状态与同步状态速查

本练习涉及的核心状态术语，与仓库 ArgoCD Application Health 问答 相互印证：

同步策略方面（见 ArgoCD Syncs 问答）：

• 手动同步：ArgoCD 只标记差异、不自动纠正——这正是本练习采用的方式；
• 自动同步：检测到差异即自动应用 Git 期望状态；
• 自动清理（Auto-Prune）：开启后，仓库中删除的文件/内容对应资源也会被移除；
• 自愈（Self-Heal）：人工改动集群后自动纠正为期望状态。

小结与延伸阅读

通过本练习，你完整走通了 GitOps 的"人工漂移 → 检测 → 恢复"闭环：用kubectl scale制造 out-of-sync，再用argocd app get/argocd app sync/argocd app wait（或 UI 的 Refresh + Sync）把集群拉回 Git 期望状态。这套操作是日常排障、审计"谁改坏了集群"的基础功。

想继续深入 ArgoCD，仓库还提供了相邻练习与问答资源：

• Sync App - Git 练习：从"仓库变更"视角体验同一同步机制；
• App Creation 练习：创建被 ArgoCD 跟踪的应用（含 CLI 与 UI 两种方式）；
• ArgoCD Helm 练习：用 ArgoCD 跟踪 Helm Chart；
• ArgoCD 完整问答集：覆盖同步周期配置（timeout.reconciliation）、手动/自动同步、自愈、App of Apps 等进阶主题；
• Argo Rollouts 练习 与 Blue/Green 练习：基于 Rollout 的渐进式发布与自动回滚。

• 文档
• 教程
• DevOps
• 运维