推式push-based流水线如 Github Actions SSH 到主机执行 deploy.sh用 GitHub Environment required reviewer 做人工放行闸门。代价是生产 SSH 凭据进 GitHub Secrets可用 command 强制命令的受限 key 把权限收窄到只能跑 deploy.sh。拉式pull-based / GitOps主机上跑一个 agent 监听 GHCR/git 变化并自行应用。凭据方向反过来GitHub 拿不到生产权限。K8s 世界的 Argo CD / Flux 就是这一派也正因如此从 CI 里 kubectl apply这种做法本身在今天已经算过时了。介绍一下这两种部署方式文章目录推式Push-based与拉式Pull-based / GitOps部署方式详解一、推式部署Push-based工作原理典型流程安全闸门设计优点缺点二、拉式部署Pull-based / GitOps工作原理典型流程关键架构优势优点缺点三、对比总结四、一句话总结推式Push-based与拉式Pull-based / GitOps部署方式详解一、推式部署Push-based工作原理┌─────────────┐ SSH / API 调用 ┌─────────────┐ │ CI/CD │ ───────────────────▶ │ 生产环境 │ │ 流水线 │ 我来帮你部署 │ 主机/K8s │ └─────────────┘ └─────────────┘CI/CD 流水线主动连接到目标环境把构建好的制品镜像、二进制、配置文件等推送过去并执行部署动作。典型流程开发者 push 代码 → 触发 CICI 构建镜像 / 编译产物CI 通过SSH连接到生产主机执行deploy.sh或者 CI 调用kubectl apply把 manifest 推到集群安全闸门设计用GitHub Environment required reviewer做人工审批——流水线跑到生产阶段前必须有人点ApproveSSH 密钥存入 GitHub Secrets可用command受限密钥收窄权限# ~/.ssh/authorized_keys command/opt/deploy/deploy.sh,no-pty,no-port-forwarding ssh-rsa AAAA...这样即使密钥泄露攻击者也只能执行deploy.sh无法获得交互式 shell。优点优点说明简单直观一条脚本就能搞定适合小团队 / 早期项目反馈即时部署日志直接出现在 CI 输出里成功失败一目了然无需额外组件不需要在目标环境运行 agent缺点缺点说明凭据暴露面大生产环境 SSH 密钥 / kubeconfig 必须放在 CI 侧GitHub Secrets权限蔓延风险一旦 CI 被攻破恶意 PR 触发 workflow攻击者拿到生产凭据环境漂移如果有人绕过 CI 手动改了生产环境CI 不知道也没有记录扩展性差环境越多要管理的凭据和连接就越多二、拉式部署Pull-based / GitOps工作原理┌─────────────┐ ┌─────────────────────┐ │ Git Repo │ ◀── 持续轮询/监听 ── │ 生产环境内的 Agent │ │ (单一真相源) │ │ (Argo CD / Flux) │ └─────────────┘ └─────────────────────┘ ▲ │ │ ▼ CI 只负责 自行 apply 变更 构建 push 镜像 我来拉取最新状态注Argo CD / Flux 是目前最主流的两款 GitOps 持续交付CD工具生产环境内部运行一个 Agent指运行在生产环境Kubernetes 集群内部的代理程序/控制器。它们负责持续监控 Git 仓库中的配置并自动将这些配置同步、应用到生产集群中它持续监听 Git 仓库或镜像仓库如 GHCR的变化发现新版本后自行拉取并应用。典型流程开发者 push 代码 → 触发 CICI只负责构建镜像并 push 到 GHCR或更新 Git 仓库里的 manifest生产环境中的Argo CD / Flux Agent检测到变更Agent在集群内部执行kubectl apply完成部署如需人工放行Agent 会暂停等待审批如 Argo CD 的 Sync 审批关键架构优势┌──────────────────────────┐ │ 信任边界防火墙 │ │ │ CI 侧不可信 │ 生产侧高信任 │ ──────────────── │ ────────────────────── │ GitHub Actions │ Argo CD Agent │ ❌ 没有 kubeconfig│ ✅ 有集群权限 │ ❌ 没有 SSH 密钥 │ ✅ 有镜像拉取凭据 │ │ │ └──────────────────────────┘凭据方向反过来了CI 永远拿不到生产环境的权限生产凭据只存在于生产环境内部。优点优点说明安全性高CI 侧零生产凭据攻击面大幅缩小环境一致性Git 是单一真相源Single Source of Truth环境状态可随时审计和回滚自动修复漂移Agent 持续对比 Git 期望状态与实际状态有人手动改集群会被自动纠正多环境扩展好每个环境跑自己的 Agent各自监听不同的 Git path/branch缺点缺点说明复杂度更高需要在生产环境部署和维护 Argo CD / Flux反馈延迟部署结果不在 CI 日志里需要去看 Agent 的状态面板学习曲线团队需要理解 GitOps 理念、Reconciliation Loop 等概念三、对比总结维度推式Push拉式Pull / GitOps谁执行部署CI 流水线生产环境内的 Agent凭据在哪CI 侧GitHub Secrets生产侧Agent 本地安全模型CI 信任 → 生产生产自治CI 不信任典型工具GitHub Actions SSH/kubectlArgo CD, Flux适用场景小团队、早期项目、简单主机部署中大规模、K8s 原生、多环境kubectl apply 在哪跑CI 里已过时 ❌参考文章为什么说“CI 里跑 kubectl apply“已过时集群内 Agent 里推荐 ✅四、一句话总结推式CI “拿着钥匙去开门”——简单但钥匙容易丢。拉式生产环境自己看门、自己取快递——CI 只负责把包裹放到门口。在现代 K8s 环境下拉式 / GitOps 已经成为行业共识。如果你还在 CI 里写kubectl apply -f确实是时候考虑迁移到 Argo CD 或 Flux 了。