从DevOps到GitOps：自动化再进化，运维的未来不靠“人”，靠“流

——作者：Echo_Wish

兄弟姐妹们，今天咱聊一个既火、又被很多人“理解错”的话题——
DevOps 到 GitOps：自动化的再升级。

说实话，这两个词你随便丢给两个技术人，他们可能会告诉你完全不同的理解。有人说 GitOps 是 DevOps 2.0，有人说它是声明式运维，有人说它就是把 YAML 写进 Git……总之越聊越玄乎。

但其实啊，从我这些年的实战经验来看：
DevOps 是“人推动系统”，GitOps 是“系统推动系统”。
一个靠人（工具 + 流程），一个靠 Git（事实源 + 自动化控制）。
一个是“自动化”，一个是“自动化 + 自愈 + 不可变 + 声明式”。

今天我就和你掏心窝子聊聊：

• GitOps 到底解决了 DevOps 解决不了的问题？
• Kubernetes 上 GitOps 为什么这么香？
• 我们怎么从 0 到 1 把 GitOps 落下去？
• 用 Argo CD / Flux 能做到什么？
• 以及——它有什么坑？

整个内容我尽量讲人话，再配点代码示例，让你真正“懂了就能用”。

一、DevOps 的极限在哪里？为什么需要 GitOps？

DevOps 的目标你我都熟：
开发与运维协作，自动化 CI/CD，提高上线效率。

但 DevOps 在云原生时代，遇到了几个“天花板”：

① DevOps 解决不了环境漂移（Drift）

典型场景：

• 开发说线上是 4 副本，运维看监控怎么是 5 副本？
• YAML 本地一套、流水线一套、线上正在跑一套，哪个是真的？
• 本地改完 YAML 忘了 push，线上永远乱。

环境永远“不一致”。
你说心累不心累？

② DevOps 强调流水线，但流水线只管“推”，不管“对”

DevOps 的核心动作是：

开发 push → CI/CD → 部署 → 上线

但 CI/CD 一旦把 yaml push 上去，CD 就算成功，它并不会持续检查：
“线上是否还符合 Git 的目标状态？”

被人临时改一把 kubectl apply，状态就乱了。

③ DevOps 自动化有限，不能保证集群的“最终一致性”

DevOps 的自动化是执行一次性的，但 GitOps 的自动化是持续的、反复的、永不停止的。

二、GitOps 是啥？一句话讲清楚

兄弟，用最简单的比喻：

Git 是国家法律，Kubernetes 是社会，而 GitOps 是警察部队。

法律写清楚：应该是什么样。
警察负责：让现实世界始终符合法律。

所以 GitOps 的本质就是：

✔ 所有环境状态，全部存Git（声明式）
✔ 集群自动拉取配置，不是你推给它（Pull 模式）
✔ 持续对比实际状态与Git状态（持续对齐）
✔ 偏差了自动纠正（自愈能力）

图大概是这样的（纯ASCII，也挺形象）：

   Git Repo  <---- Declarative config
      |
      V
+-------------+
|  GitOps     |   Argo CD / Flux
|  Controller |
+-------------+
      |
      V
 Kubernetes Cluster

一句话总结：
以前是人推系统，现在是系统“拉”配置，把一切做到自动化自治。

三、到底怎么用？来，我们一起上 Argo CD

下面我用 Argo CD 做例子，因为它最容易理解、最容易上手，也最容易看到效果。

① 安装 Argo CD（K8s 一条命令）

kubectl create namespace argocd

kubectl apply -n argocd \
  -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

② 给 Argo CD 建一个应用，让它自动部署你的服务

比如你把你的 K8s yaml 存在 Git：

git repo: https://github.com/you/app-deploy
path: manifests/

Argo CD 的 Application 配置就像这样：

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  namespace: argocd
spec:
  destination:
    namespace: default
    server: https://kubernetes.default.svc
  source:
    repoURL: https://github.com/you/app-deploy
    targetRevision: main
    path: manifests
  project: default
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

这段配置有几层魔力：

• automated → Git 一变更，K8s 自动同步
• prune → Git 删掉的资源，线上自动删
• selfHeal → 谁擅自 apply，Argo CD 秒恢复

这就是 GitOps 最强的“自动治理能力”。

四、来，感受一下 GitOps 的“超能力”

能力1：真正的自动化（Git才是控制面）

你只要：

git add .
git commit -m "update replica to 5"
git push

K8s 就会自动变成 5 副本。
你甚至不需要 kubectl。

能力2：环境永远不会漂移

你想象一下：

某个同事手抖：

kubectl scale deploy my-app --replicas=8

Argo CD 立刻发现不一致：

Git：5 副本  
实际：8 副本  
→ 自动恢复到 5

这就叫“最终一致性”。

能力3：版本全可回溯

Git 是天然审计系统：

• 谁改的？
• 改了啥？
• 改坏了怎么 rollback？

一句命令：

git revert HEAD

集群瞬间恢复。

能力4：多环境管理从乱到稳

GitOps 让环境变得有秩序：

environments/
  dev/
  staging/
  prod/

你甚至可以做自动 Promotion 流程：

• dev 自动部署
• 测试通过 → 自动同步到 staging
• 人工审批 → 推到 prod

这在 DevOps 里难度非常高，在 GitOps 里非常自然。

五、实际生产经验：GitOps 最大的价值不是自动化，而是“减少人为破坏”

很多团队上 GitOps 的原因非常现实——
运维不是被系统累死，是被“人”折磨死的。

• 某个同事 apply 了旧版本 yaml
• 某个临时环境没删干净
• 手工操作太多导致线上环境不一致
• 某个测试人员把 staging 配置 apply 到 production
• 某人忘了 push yaml

这些场景，你是不是全都经历过？

GitOps 的出现就是为了解决“人”这个最大变数。

Git 是唯一事实源
所有操作基于 Git
所有部署来自 Git
Git 就是法律
集群只能照 Git 来办事

世界清净了。

六、GitOps 的坑，我也必须讲清楚

坑1：YAML 暴增（不可回避）

GitOps 要声明式，一切都得 YAML。
但是建议配合 Kustomize / Helm，不然你会疯掉。

坑2：初期落地成本略高

特别是：

• CRD 多
• YAML 多
• 团队需要规范化流程
• 必须人人遵守 Git 流程

但一旦落地成功，非常丝滑。

坑3：适合 K8s，不适合传统 VM 环境

真实话，有些 GitOps 工具对 VM 不是很友好，K8s 才是最佳土壤。

七、最后：为什么我说 GitOps 是 DevOps 的“再升级”？

DevOps 的精神是：

让开发与运维合作更好，让部署更快，让交付更自动化。

GitOps 的精神是：

让系统具备自驱力，让状态永远一致，让自动化从“被动执行”变成“主动治理”。