[!info] related notes

• 所属 MOC: 云原生 MOC
• 前置概念: Kubernetes MOC, CI/CD MOC
• 相关: github-actions, watchtower-auto-deploy, release-please-automated-versioning

部署策略

一句话定义

部署策略决定了新版本代码如何安全地交付到生产环境，以及出问题时如何快速回滚。

---

Rolling Update（滚动更新）

原理： 逐步用新版本 Pod 替换旧版本 Pod。在更新过程中，始终有可用的 Pod 在服务。

优点：

• 零停机
• Kubernetes 原生支持（Deployment 默认策略）
• 配置简单

缺点：

• 更新过程中新旧版本共存，需要兼容
• 回滚需要重新部署旧版本

适用： 大多数常规更新。

---

Canary（金丝雀发布）

原理： 先将少量流量导入新版本（如 5%），观察指标正常后逐步扩大比例，直到全量切换。

优点：

• 爆炸半径小，问题只影响少量用户
• 可以在真实流量下验证新版本

缺点：

• 需要流量控制能力（Ingress / Service Mesh）
• 需要监控指标来判断是否继续

适用： 重要更新、不确定影响范围的变更。

---

Blue-Green（蓝绿部署）

原理： 同时维护两个完整环境（蓝 = 当前版本，绿 = 新版本）。新版本在绿环境验证通过后，一次性将流量切换到绿环境。

优点：

• 切换瞬间完成，用户体验无感知
• 回滚极快（切回蓝环境）

缺点：

• 需要双倍资源
• 数据库迁移需要兼容两个版本

适用： 关键业务、不能有任何停机的场景。

---

GitOps

原理： 不直接手动改集群，而是把部署配置放进 Git 仓库。集群状态由 Git 仓库声明。Git 变了，集群自动同步。出问题通过 Git 历史回滚。

Git becomes the source of truth.

核心工具：

• Argo CD — 监听 Git 仓库变更，自动同步到 Kubernetes 集群
• Flux — CNCF 孵化项目，类似功能

GitOps 工作流：

开发者推送代码
    ↓
CI 流水线构建镜像
    ↓
更新 Git 仓库中的部署配置（镜像版本号）
    ↓
Argo CD 检测到 Git 变更
    ↓
自动同步到 Kubernetes 集群
    ↓
健康检查通过
    ↓
如果出问题 → Git revert → 集群自动回滚

优点：

• 所有变更可审计（Git 历史）
• 回滚就是 Git revert
• 声明式，与 Kubernetes 理念一致
• 多环境管理统一

缺点：

• 学习曲线较陡
• 需要额外的工具链
• Secrets 管理需要特殊处理

---

策略对比

策略	停机时间	回滚速度	资源开销	复杂度
Rolling Update	无	慢	低	低
Canary	无	快	低	中
Blue-Green	无	极快	高（双倍）	中
GitOps	无	极快	低	高

---

选型建议

• 个人项目 / 小团队： Rolling Update（K8s 默认）+ Watchtower 自动部署
• 中型团队： Canary 发布 + 完善监控
• 大型团队 / 关键业务： GitOps（Argo CD）+ Canary + 完善的可观测性
• 单机部署： Watchtower 轮询更新（BodySense 当前方案）

---

相关 MOC

• 云原生 MOC
• Kubernetes MOC
• CI/CD MOC