前言上一篇讲了 GitOps 四大原则本篇用一个完整的对比来展示推模型和拉模型在实际操作中的差异。你会看到同样一个部署需求两种模式下的流程、安全模型、回滚方式完全不同。一、同一个需求两种实现需求将myapp的镜像从v1.0更新到v2.0部署到生产 K8s 集群。推模型实现传统 CI/CD步骤1: 开发者提交代码 git commit -m v2.0 git push 步骤2: CI 流水线触发 Jenkins/GitLab CI/Actions 执行 步骤3: CI 构建镜像 docker build -t registry.com/myapp:v2.0 . docker push registry.com/myapp:v2.0 步骤4: CI 部署到集群← 这里是关键 # CI 需要 kubeconfig 来操作集群 export KUBECONFIG$PROD_KUBECONFIG kubectl set image deployment/myapp appregistry.com/myapp:v2.0 -n prod kubectl rollout status deployment/myapp -n prod拉模型实现GitOps步骤1: 开发者提交代码 git commit -m v2.0 git push 步骤2: CI 流水线触发 Jenkins/GitLab CI/Actions 执行 步骤3: CI 构建镜像 docker build -t registry.com/myapp:v2.0 . docker push registry.com/myapp:v2.0 步骤4: CI 更新 Git 中的部署清单← 这里是关键 # CI 不操作集群只更新 Git 仓库 cd deploy-repo sed -i s|myapp:v1.0|myapp:v2.0| overlays/prod/deployment.yaml git commit -am update image to v2.0 git push origin main 步骤5: GitOps 工具自动同步自动完成无需 CI 参与 # ArgoCD 检测到 Git 仓库变化 # ArgoCD 在集群内部执行同步 kubectl set image deployment/myapp appregistry.com/myapp:v2.0 -n prod kubectl rollout status deployment/myapp -n prod二、安全模型对比推模型的安全问题推模型的权限分布: CI/CD 工具持有: ✓ 镜像仓库凭证 ✓ 生产集群的 kubeconfig ← 危险 ✓ kubectl 命令执行权限 风险: 1. CI 日志可能泄漏 kubeconfig 2. CI Runner 可能被入侵 3. 有 CI 权限的人可以操作生产集群 4. kubeconfig 有过期问题需要定期轮换拉模型的安全优势拉模型的权限分布: CI/CD 工具持有: ✓ 镜像仓库凭证 ✓ Git 仓库的写权限 ← 只能改配置 K8s 集群内的 GitOps 工具持有: ✓ 集群内的操作权限 ✓ 但只从 Git 仓库读取配置 CI 和集群之间完全解耦: → CI 没有任何集群权限 → 入侵 CI 的人只能改 Git 配置 → Git PR Review 是第一道防线 → 集群内的 GitOps 工具是第二道防线权限对比矩阵权限推模型持有方拉模型持有方镜像仓库读写CICIGit 仓库读写CICI部署清单仓库K8s 集群操作CI集群内 Agent生产环境变更CI 直接操作Git PR Agent 自动三、审计能力对比推模型的审计推模型审计信息来源: 1. CI 流水线日志 → 可能被清理不持久 2. K8s 事件 → 只保留1小时 3. Jenkins/GitLab 构建记录 → 保留数量有限 问题: Q: 谁在什么时候把 v1.0 改成了 v2.0 A: 查 Jenkins 日志... 已清理 Q: 为什么集群里有手动创建的 ConfigMap A: 不知道没有记录拉模型的审计拉模型审计信息来源: 1. Git log → 永久保存不可篡改 2. GitOps 工具的操作日志 → 在集群内持久化 3. PR/MR → 完整的审查记录 回答: Q: 谁在什么时候把 v1.0 改成了 v2.0 A: git log -- deploy/overlays/prod/deployment.yaml commit abc123 by zhangsan at 2026-01-15 14:30 PR #42 reviewed by lisi update image to v2.0 Q: 为什么集群里有手动创建的 ConfigMap A: ArgoCD 会检测到非 Git 管理的资源 → 告警: 检测到未管理的资源 configmap/manual-config → 或自动清理: prunetrue四、回滚能力对比推模型回滚# 推模型回滚流程: # 1. 找到上一个镜像版本 docker images | grep myapp # 查看可用版本 # 或查 CI 历史 # 2. 重新触发部署 kubectl set image deployment/myapp appregistry.com/myapp:v1.0 -n prod # 3. 等待滚动更新 # 问题: # - 可能找不到上一个版本的镜像 # - 需要找 CI 的部署配置 # - 如果有配置回滚不只是镜像很难还原 # - 总耗时 5-15 分钟拉模型回滚# 拉模型回滚流程: # 1. Git revert git revert HEAD git push origin main # 2. ArgoCD 自动检测到 Git 变化 # 3. 自动同步到上一个版本 # 优势: # - 完整回滚镜像配置所有 YAML 变更 # - 1分钟内完成 # - Git 历史保证可以回滚到任意版本 # - 不需要找镜像版本五、漂移处理对比推模型有人手动改了集群: kubectl scale deployment myapp --replicas1 推模型: → CI 不知道有人改了集群 → 下次 CI 部署时会覆盖如果还记得设置 replicas → 如果 CI 没有设置 replicas手动修改会一直存在 → 漂移不会被检测到问题积累拉模型有人手动改了集群: kubectl scale deployment myapp --replicas1 拉模型: → ArgoCD 下次协调30秒-3分钟内 → 检测到漂移: Git(replicas3) ≠ Cluster(replicas1) → selfHealtrue: 自动修复 → replicas 恢复为 3 → 发送告警: 检测到漂移已自动修复 → 漂移在分钟级别被发现和修复六、什么时候该用哪种模型推模型适用场景场景原因非 K8s 环境GitOps 工具主要面向 K8s物理机/VM 部署需要 SSH 脚本数据库变更DDL 不是声明式的快速原型不需要 GitOps 的完整流程小团队简单项目GitOps 的复杂度可能不值拉模型适用场景场景原因K8s 生产环境GitOps 工具原生支持合规审计要求Git 提供完整审计链多环境管理Git 分支/目录对应环境多集群部署统一 Git 仓库管理需要漂移检测防止手动修改导致不一致混合模式实际企业中常见的混合模式: 应用部署 → GitOps拉模型 用 ArgoCD/Flux 管理 K8s 应用 基础设施 → Terraform推模型 用 CI 触发 terraform apply 管理 VPC/安全组等 数据库变更 → Flyway推模型 用 CI 触发数据库迁移 非容器化应用 → Ansible推模型 用 CI 触发 Ansible Playbook培训要点不要追求全 GitOps。K8s 应用用 GitOps基础设施用 Terraform数据库用 Flyway物理机用 Ansible——各取所长。GitOps 是手段不是目的。七、本篇要点回顾推模型CI 持有集群权限直接部署拉模型CI 只更新 Git集群内 Agent 同步安全核心差异推模型的 CI 有生产集群 kubeconfig拉模型的 CI 不需要审计差异推模型依赖 CI 日志易丢失拉模型用 Git log永久保存回滚差异推模型要找镜像版本重新部署拉模型只需 git revert漂移差异推模型不检测漂移拉模型分钟级检测自动修复混合模式K8s 用 GitOps 基础设施用 Terraform 数据库用 Flyway下一篇预告《工具生态ArgoCD、Flux、Jenkins X 对比选型》——了解了推拉模型的差异接下来看看拉模型有哪些工具可选。