前言如果说 CI/CD 解决了代码到镜像的自动化那 GitOps 解决的是镜像到运行环境的自动化——而且是用一种更安全、更可审计的方式。本篇带你理解 GitOps 的本质以及它如何从基础设施即代码IaC一步步演进而来。一、部署方式的演进四个时代时代1: 手动部署FTP SSH 运维手动拉代码、编译、重启服务 问题不可重复、不可审计、容易出错 时代2: 脚本自动化Shell Ansible 写脚本自动化部署 问题脚本本身可能变环境状态不确定 时代3: 基础设施即代码Terraform Helm 用代码描述目标状态工具执行变更 进步但变更仍然由 CI/CD 推送触发 时代4: GitOpsArgoCD Flux Git 仓库作为唯一可信源工具持续协调 突破声明式 持续协调 Git 审计推模型 vs 拉模型传统 CI/CD推模型: CI 流水线 → 构建镜像 → kubectl apply → K8s 集群 ↑ 推送方 ↑ 被动接收 问题 1. CI 需要集群的 kubeconfig安全风险 2. 有人手动改了集群CI 不知道 3. 不知道集群实际状态与期望状态的差异 GitOps拉模型: Git 仓库期望状态 ←→ GitOps 工具 ←→ K8s 集群实际状态 ↑ 在集群内部运行 优势 1. GitOps 工具在集群内运行CI 不需要集群权限 2. 持续检测差异发现有人手动改了集群会自动修复 3. 所有变更都在 Git 中审计培训要点推模型和拉模型最本质的区别不是技术实现而是谁持有集群的访问权限。推模型中 CI/CD 持有 kubeconfig安全风险大拉模型中集群内的 Agent 持有权限CI 只需要 push 代码到 Git。二、从 IaC 到 GitOpsIaC基础设施即代码用代码描述基础设施# Terraform — 声明基础设施 resource aws_instance web { ami ami-12345678 instance_type t3.micro count 3 }# Helm — 声明 K8s 应用 replicaCount: 3 image: repository: myapp tag: 1.0.0IaC 的进步基础设施可以用代码管理、版本控制、可复现。但 IaC 仍然依赖外部触发——你需要手动运行terraform apply或helm install。GitOps 在 IaC 基础上的升级IaC: 代码描述状态 → 手动执行变更 → 集群变化 ↑ 一次性触发 GitOps: Git 仓库描述状态 → 工具持续协调 → 集群持续与 Git 保持一致 ↑ 持续触发一直在跑GitOps 的核心增量持续协调Continuous Reconciliation——工具持续监控 Git 仓库和集群的实际状态发现差异自动修复。三、GitOps 的实际工作流程完整流程1. 开发者修改代码 → 提交 PR → 合并到 main 2. CI 流水线构建镜像 → 推送到镜像仓库 3. CI 更新 Git 中的部署清单修改 image tag 4. GitOps 工具检测到 Git 仓库变化 5. GitOps 工具将集群状态同步到与 Git 仓库一致 6. 集群中的 Pod 更新为新版本 ┌──── CI 只负责到这里 ────┐ ↓ ↓ 开发者 → Git 仓库(代码) → CI → 镜像仓库 ↓ Git 仓库(部署清单) ← CI 更新镜像版本 ↓ GitOps 工具(ArgoCD/Flux) ↓ K8s 集群持续同步具体示例# 开发者提交代码 git commit -m feat: add order API git push origin main # CI 构建镜像 docker build -t registry.com/myapp:abc123 . docker push registry.com/myapp:abc123 # CI 更新部署清单仓库中的镜像版本 cd deploy-repo sed -i s|image: registry.com/myapp:.*|image: registry.com/myapp:abc123| deployment.yaml git commit -am update image to abc123 git push origin main # 到这里 CI 的任务就结束了 # 下面是 GitOps 工具自动完成的 # ArgoCD 检测到 Git 仓库变化3秒内 # ArgoCD 在集群中执行 kubectl apply # 新版本的 Pod 开始滚动更新 # 用户访问到新版本踩坑提示GitOps 流程中 CI 不直接操作集群。最常见的错误是在 CI 中用 kubectl apply——这又回到了推模型。正确的做法是 CI 只更新 Git 仓库中的清单文件。四、GitOps 适用的场景适合 GitOps 的场景场景为什么适合K8s 应用部署GitOps 工具原生支持 K8s多环境管理不同环境对应不同 Git 目录/分支多集群部署一个 Git 仓库管理多个集群合规审计要求所有变更在 Git 中有记录回滚需求Git revert 即回滚不太适合的场景场景为什么不适合替代方案非 K8s 环境GitOps 工具主要面向 K8sAnsible/Terraform数据库 DDL声明式不适用于有状态的变更Flyway/Liquibase物理机部署不是 K8s 原生Ansible快速原型验证GitOps 增加流程复杂度直接 kubectl apply五、GitOps 的收益收益一安全审计传统方式: who did what when → 依赖 Jenkins 日志可能被清理 集群当前状态 → kubectl get all但不知道为什么是这个状态 GitOps: who did what when → git log永久保存 集群当前状态 → git show HEAD与 Git 仓库完全一致 变更审批 → Git PR Review每次变更都有审查记录收益二快速回滚# 传统回滚找上一个镜像版本kubectl set image # GitOps 回滚git revert git revert HEAD git push origin main # ArgoCD 自动将集群回滚到上一个版本 # 整个过程 1分钟收益三漂移检测有人手动修改了集群: kubectl edit deployment myapp → 副本数从 4 改为 2 GitOps 工具检测到漂移: → 集群状态(2) ≠ Git 仓库状态(4) → 自动修复副本数恢复为 4 → 发送漂移告警通知收益四CI/CD 解耦传统: CI 需要: 镜像仓库凭证 K8s kubeconfig kubectl → CI 持有生产集群权限安全风险大 GitOps: CI 需要: 镜像仓库凭证 Git 仓库写权限 → CI 不需要任何集群权限 → 集群内的 GitOps 工具持有权限六、本篇要点回顾GitOps 是从手动部署 → 脚本自动化 → IaC → GitOps 的演进核心区别是拉模型集群内的 Agent 主动从 Git 拉取配置CI 不需要集群权限完整流程CI 构建镜像 → 更新 Git 中的清单 → GitOps 工具同步集群四大收益安全审计、快速回滚、漂移检测、CI/CD 解耦最适合 K8s 环境非 K8s 场景用传统 IaC下一篇预告《四大原则声明式、版本控制、自动应用、持续协调》——深入 GitOps 的四个核心原则理解为什么这些原则让 GitOps 成为更安全的交付方式。