为什么说“CI 里跑 kubectl apply“已过时？（最小权限原则、CI推式部署、GitOps拉式部署）

维度推式Push拉式Pull / GitOps谁执行部署CI 流水线生产环境内的 Agent凭据在哪CI 侧GitHub Secrets生产侧Agent 本地安全模型CI 信任 → 生产生产自治CI 不信任典型工具GitHub Actions SSH/kubectlArgo CD, Flux适用场景小团队、早期项目、简单主机部署中大规模、K8s 原生、多环境kubectl apply 在哪跑CI 里已过时 ❌集群内 Agent 里推荐 ✅为什么说CI 里跑 kubectl apply已过时文章目录为什么说CI 里跑 kubectl apply已过时1. 安全风险 — CI 信任 → 生产模型脆弱2. 状态漂移无法自愈3. 网络打通困难4. 可观测性差5. 环境一致性难保证一句话总结⚠️ 但也不是绝对过时为什么说CI 里跑 kubectl apply已过时这主要源于安全性、可观测性和运维实践的演进。以下是核心原因1. 安全风险 — CI 信任 → 生产模型脆弱问题说明凭据暴露面大CI 系统如 GitHub Actions需要持有生产集群的 kubeconfig/token一旦 CI 被攻破供应链攻击、恶意 PR 触发 workflow生产集群就暴露了权限难以收敛CI 需要集群级写权限违反最小权限原则审计困难谁、何时、部署了什么散落在 CI 日志里难以统一审计2. 状态漂移无法自愈CI: kubectl apply → 完事 ✅ 然后就不管了CI 是一次性触发的apply 完就结束了如果有人手动改了集群kubectl edit或者节点异常导致 Pod 挂了CI 不会感知也不会修复结果实际状态 ≠ Git 声明状态状态漂移而Pull 模式Argo CD / Flux的 Agent 持续在集群内运行Agent: 每隔 N 秒 diff Git vs 集群 → 发现漂移 → 自动 reconcile ✅3. 网络打通困难CI 跑在公网GitHub Actions 的 runner IP 不固定要访问生产集群需要开放 API Server 公网端口危险或者搭 VPN / Tunnels增加复杂度Pull 模式的 Agent从集群内部主动拉取 Git 仓库不需要入站连接网络模型更安全4. 可观测性差CI 推式GitOps 拉式部署成功与否看 CI 日志Argo CD UI 实时展示所有资源状态、健康度、diff无统一视图Git 是唯一真相源Single Source of Truth回滚 重新跑 CI回滚 git revertAgent 自动同步5. 环境一致性难保证CI 里的kubectl版本、kustomize 版本、helm 版本可能与本地开发不一致Pull 模式的 Agent 运行在集群内版本固定、环境一致、可复现一句话总结“CI 里 kubectl apply” 把生产集群的钥匙交给一个临时的、不可控的外部系统然后祈祷它不会被滥用。“Agent 里 kubectl apply” 集群自己看着 Git自治、自愈、自闭环。这就是为什么 Argo CD、Flux 等 GitOps 工具成为中大规模 K8s 部署的事实标准。⚠️ 但也不是绝对过时对于小团队、早期项目、单机 Docker/SSH 部署CI 推式仍然够用且简单。表格也标注了这一点。过时更多指的是在 K8s 原生、多环境、中大规模场景下的最佳实践已经转向 Pull 模式。