Argo CD 的默认行为是保守的:它会检测差异,但不会自行修改你的集群。每一种让它完全自动化的行为都需要显式开启,这让你可以为不同环境选择不同的自动化程度。本指南使用上一篇指南中的 webapp-dev 应用,逐一讲解每个开关。

手动同步与自动同步

没有 syncPolicy.automated 块的 Application 是手动的。Argo CD 会将 Git 与集群进行比较,在两者不同时将应用标记为 OutOfSync,但在有人点击 UI 中的 Sync 或运行 argocd app sync 之前,不会应用任何内容。

许多团队在 dev 和测试环境使用自动同步,而保持生产环境为手动,这样在团队信任流水线之前,每次生产发布都由人来批准。

开启自动同步

在应用的 syncPolicy 中添加 automated 块:

spec:
  syncPolicy:
    automated: {}

这样,任何改变期望状态的新提交都会被自动应用,无需点击。关于时序有两点说明:

• Argo CD 通过轮询仓库来检测新提交,默认每三分钟一次。这与同步策略无关。策略只决定检测到的差异是否会被应用。
• 若要立即响应,请配置从 Git 托管服务到 Argo CD /api/webhook 端点的 webhook,或者在测试时点击 UI 中的 Refresh。

添加 prune(修剪)

默认情况下,自动同步会创建和更新资源,但不会删除任何东西。如果你在 Git 中重命名或删除了一个清单,旧对象会留在集群中,应用也会因为这个残留而显示 OutOfSync。要选择开启删除:

spec:
  syncPolicy:
    automated:
      prune: true

要试一试,把 dev/deployment.yaml 中的 Deployment 从 webapp 重命名为 webapp-v2 并提交。Argo CD 会创建新的 Deployment 并移除旧的。对于手动同步,你可以用 argocd app sync webapp-dev --prune 执行一次 prune,或在同步对话框中勾选 Prune。Prune 会删除真实的对象,所以请有意识地开启,并对持有状态的资源保持谨慎。

添加 self-heal(自愈)

自动同步响应 Git 中的变化。Self-heal 则还会响应集群中的变化:

spec:
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

通过做一个 Git 不知道的手动修改来测试它:

kubectl scale deployment webapp-v2 -n webapp --replicas=5
kubectl get pods -n webapp -w

额外的 Pod 会启动,随后 Argo CD 会将 Deployment 恢复为 Git 中声明的两个副本。这正是目的所在:Git 始终是唯一的事实来源。如果你的团队还没有准备好让手动修改被自动还原,请保持 selfHeal 关闭。Argo CD 仍会将应用显示为 OutOfSync,所以漂移依然可见。如果想被主动告知,可以添加通知。

安全地回滚

要回到更早的已部署状态,打开应用的 History and Rollback 视图,选择之前的修订版本并回滚。对应的 CLI 命令是:

argocd app history webapp-dev
argocd app rollback webapp-dev <ID>

回滚要求自动同步处于关闭状态。否则 Argo CD 会立即把应用重新同步到最新提交,从而撤销回滚。先用 argocd app set webapp-dev --sync-policy none 将其禁用。回滚之后应用是 OutOfSync,因为 Git 领先于当前运行的内容。请把回滚当作应急手段,而不是修复方案。持久的修复方式是对有问题的提交执行 git revert 并推送,然后重新启用自动同步,让 Git 与集群再次一致。