生产环境部署：推式部署（Push-based）与拉式部署（Pull-based / GitOps）部署方式详解（Argo CD / Flux、GHCR、kubectl apply、GitOps）
- 推式（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 代码 → 触发 CI
- CI 构建镜像 / 编译产物
- CI 通过SSH连接到生产主机，执行
deploy.sh - 或者 CI 调用kubectl apply把 manifest 推到集群
安全闸门设计
- 用GitHub Environment + required reviewer做人工审批——流水线跑到生产阶段前必须有人点"Approve"
- SSH 密钥存入 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 代码 → 触发 CI
- CI只负责构建镜像并 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/kubectl | Argo CD, Flux |
| 适用场景 | 小团队、早期项目、简单主机部署 | 中大规模、K8s 原生、多环境 |
| kubectl apply 在哪跑 | CI 里（已过时 ❌）（参考文章：为什么说“CI 里跑 kubectl apply“已过时？） | 集群内 Agent 里（推荐 ✅） |
四、一句话总结
推式：CI “拿着钥匙去开门”——简单但钥匙容易丢。
拉式：生产环境"自己看门、自己取快递"——CI 只负责把包裹放到门口。
在现代 K8s 环境下，拉式 / GitOps 已经成为行业共识。如果你还在 CI 里写kubectl apply -f，确实是时候考虑迁移到 Argo CD 或 Flux 了。