GitOps 实战：让回滚像 git revert 一样简单

用 Argo CD 把集群状态收敛到 Git，回滚不再是手忙脚乱的线上操作，而是一次可审计的提交。

「上线出问题了，快回滚！」—— 传统模式下这句话意味着有人要登上跳板机、翻历史镜像、手敲 kubectl。GitOps 想解决的，正是把这种高压操作变成一次普通的 Git 提交。

核心理念

GitOps 把期望状态声明在 Git 里，由控制器（如 Argo CD）持续把集群实际状态向 Git 收敛：

Git 是唯一事实来源（single source of truth）;
所有变更都经过 PR、可评审、可审计;
回滚 = 回退 Git 提交，控制器自动把集群拉回旧状态。

一个最小同步配置

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: web
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/example/deploy.git
    targetRevision: main
    path: apps/web
  destination:
    server: https://kubernetes.default.svc
    namespace: web
  syncPolicy:
    automated:
      prune: true      # 删除 Git 中已移除的资源
      selfHeal: true   # 手动改动会被自动纠正

回滚的两种姿势

回退提交：git revert <bad-commit> 后推送，Argo CD 检测到差异自动同步回旧版本，全程留痕;
历史版本回滚：在 Argo CD UI 选中某次历史 Sync，一键 Rollback，适合紧急情况。

两种方式都比手动 kubectl set image 更安全，因为集群状态始终和 Git 对齐，不会出现「线上和仓库不一致」的漂移。

落地建议

仓库分层：应用清单与环境配置分开，用 Kustomize/Helm 管理差异;
镜像更新交给 Image Updater 或 CI，避免手改 tag;
打开 selfHeal 前，先确保团队不再直接动线上，否则会反复「打架」。

当回滚变成一次 git revert，深夜上线的心理负担会小很多。