GitOps：用 Git 管理集群状态

手工 apply 与 CI 直连的三个隐患#

前面每一章你都在用 kubectl apply -f。它简单、直接，也几乎一定会在生产环境里出这三类问题。

第一类是状态漂移。 凌晨两点线上出事，有人 kubectl edit deployment 把副本数调大顶住流量，然后在聊天群里说了一句「已处理」。第二天仓库里的 YAML 还是 3 副本，集群里是 10 副本，没人知道哪个才是真相。下次谁再 apply 一次，热修就被覆盖，事故复发。

第二类是没有审计。 谁在什么时候改了哪个字段、为什么改，这些信息只留在某个人的 shell 历史里。等你要复盘时，仓库的提交记录干干净净，集群却变了样。

第三类是把集群凭证交给流水线。 让 CI 拿着 kubeconfig 直接 kubectl apply，意味着流水线系统里存着集群的管理员权限；流水线被攻破，等于集群被交出。而且部署历史散落在每次构建的日志里，想找「上一版是什么」只能翻构建记录。

GitOps 的核心思路是：别让任何东西「推」进集群，让集群自己从 Git「拉」。

GitOps 的四个原则#

GitOps 不是某个工具的名字，而是一套约定。业界把它概括为四条，理解了这四条，选哪个工具都不迷路。

1. 声明式：系统状态全部用声明式描述（原生 YAML、Helm chart、Kustomize 都行），不写「执行步骤」。
2. 版本化且不可变：期望状态存在 Git 里，每次变更都是一次提交，历史天然可追溯、可对比、可回滚。
3. 自动拉取：集群里的代理主动从 Git 拉取并对比，而不是由 CI 推。集群凭证不出集群。
4. 持续协调：控制器不断比较「Git 里的期望」和「集群里的现实」，不一致就纠正——这就是你已经熟悉的控制器模式，只不过这次的期望来源是 Git。

开发者 ──发起 PR──▶ Git 仓库（唯一真相）
                     │
                     │ ① 拉取 + 对比（pull 模型）
                     ▼
             ArgoCD / Flux 控制器
                     │
                     │ ② apply / delete
                     ▼
                目标集群
                     ▲
                     └── ③ 漂移检测：手工改的东西会被改回去

注意第 ③ 步既是 GitOps 最大的价值，也是最容易让人踩坑的地方：你手工做的「紧急修复」会被自动抹掉。后面会讲怎么处理。

ArgoCD 与 Flux 怎么选#

两者都能实现上面四条原则，差别主要在架构和交互方式。

选型建议很朴素：团队里有人需要「看一眼现在什么状态」，选 ArgoCD；团队全是 SRE、喜欢一切皆 CRD，Flux 更顺手。 这一章用 ArgoCD 演示，因为它的界面让「漂移」这件事看得见。

动手：用 Helm 装 ArgoCD 并拿到初始密码#

helm repo add argo https://argoproj.github.io/argo-helm
helm repo update
helm search repo argo/argo-cd --versions | head -5

helm install argocd argo/argo-cd \
  --namespace argocd --create-namespace
kubectl -n argocd rollout status deploy/argocd-server
kubectl -n argocd get pods

kubectl -n argocd get secret argocd-initial-admin-secret \
  -o jsonpath='{.data.password}' | base64 -d; echo

kubectl -n argocd port-forward svc/argocd-server 8080:443

argocd login localhost:8080 --username admin --password '<上面取到的密码>' --insecure
argocd version --client

验证方式是：argocd 命名空间里的 Pod 全部 Running，argocd login 返回登录成功，UI 能进入 Applications 页面。

写第一份 Application 清单#

Application 是 ArgoCD 的核心资源，它描述「从哪个仓库的哪个路径，把什么部署到哪个集群的哪个命名空间」。下面这份清单指向官方的示例仓库，可以直接跑起来：

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

几个字段值得逐一说明：

kubectl -n argocd apply -f guestbook-app.yaml
kubectl -n argocd get applications
argocd app get guestbook
argocd app sync guestbook
kubectl -n guestbook get deploy,svc,pod

argocd app get guestbook 里的 Sync Status 变成 Synced、Health 变成 Healthy，并且 guestbook 命名空间里能看到 Deployment 和 Pod，就说明整条链路通了。

现在做一次漂移实验，这是理解 GitOps 最直观的方式：

kubectl -n guestbook scale deploy guestbook-ui --replicas=5
kubectl -n guestbook get deploy guestbook-ui

先看到 5 个副本，等一会儿（ArgoCD 默认约 3 分钟做一次协调）再执行 kubectl -n guestbook get deploy guestbook-ui，副本数会自己回到 Git 里声明的值。这就是「集群向 Git 收敛」——你改的是现实，它改的是期望，最后现实被拉回去。

同步、对比、回滚：argocd 与 kubectl 的对照#

如果你已经熟悉 kubectl，下面这张对照表能让你几分钟内上手 argocd CLI。

argocd app diff guestbook
argocd app history guestbook
argocd app rollback guestbook 1
argocd app list -o wide
kubectl -n argocd get applications -o wide

argocd app diff 在自动化流水线里特别有用：它把「集群现在和 Git 期望差在哪」列出来，等于一份人类可读的漂移报告。

App of Apps 与 ApplicationSet#

一个应用一份 Application 清单，很快会变成几十份。Kubernetes 的惯例解法是「用资源管理资源」。

• App of Apps：再写一个 Application，它的 path 指向一个目录，目录里全是其他 Application 清单。同步这一个应用，等于同步了下面所有应用。
• ApplicationSet：用一份模板加一个生成器（Git 目录列表、集群列表、Pull Request 列表）批量生成 Application。适合「同一个应用要部署到 5 个集群」这类场景。

两者都不改变 GitOps 的本质：唯一的输入仍然是 Git 仓库里的文件。

与前面章节的关系#

如果你把这一章和前面的内容对照着看，会发现一件很有意思的事：清单本身没有变。

• 第 5 章 用 YAML 描述 Pod 里写的 Pod 清单，照样能交给 ArgoCD 部署。
• 第 6 章 Deployment 的滚动更新与回滚，仍然由 Deployment 控制器完成，ArgoCD 只负责把新版本的期望写进去。
• Helm 的 chart 可以直接作为 source.path，ArgoCD 会自己渲染。
• 第 12 章 命名空间与 RBAC 里的权限模型，正好用来限制 ArgoCD 能碰哪些资源。

换句话说，GitOps 换掉的只有一件事：谁来执行 `apply`。从「人拿着 kubeconfig 敲命令」，变成「集群里的控制器从 Git 拉取」。

常见坑与速查表#

自测题#

小结#

• 手工 kubectl apply 与 CI 直连部署会带来状态漂移、缺少审计、凭证外泄三类问题。
• GitOps 的四条原则是：声明式、版本化且不可变、自动拉取、持续协调。
• ArgoCD 是中心式加可视化，Flux 是分布式加纯 CRD，两者都能落地 GitOps。
• Application 描述「从哪拉、部署到哪」，syncPolicy.automated 决定是否自动同步、是否删除与自愈。
• argocd app sync/diff/history/rollback 分别对应 apply、diff、无内建能力、手工回滚。
• GitOps 只改变「谁来 apply」，清单、控制器、RBAC 这些前面的知识全部继续有效。

练习#

1. 把 guestbook 应用的 targetRevision 从 HEAD 改成某个具体 commit，说明为什么生产上更推荐这样做。
2. 用 argocd app diff 找出一次漂移，然后加上 ignoreDifferences 让某个字段不再触发 OutOfSync，观察状态变化。
3. 想一个你手头的项目：它需要几个 Application？如果要做 App of Apps，目录结构会怎么组织？

集群状态交给了 Git，但 Git 里的清单恢复不了数据。下一章 备份与恢复 讲怎么把「删错了」变成一件小事。