部署策略

Source: Dev.to

滚动更新

它是什么
Kubernetes 逐步用新 Pod 替换旧 Pod，若配置正确可实现零停机。

工作原理

• 终止部分旧 Pod。
• 逐步创建新 Pod。
• 在过渡期间共享流量。

关键设置

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxUnavailable: 1
    maxSurge: 1

优点

• 零停机（默认行为）。
• 简单且可直接用于生产。

缺点

• 旧版本和新版本同时运行，可能会使数据库/模式更改变得复杂。

何时使用

• 大多数 Web 应用、API 和微服务。

---

重建

它是什么
先停止所有旧 Pod，然后创建新 Pod。

配置

strategy:
  type: Recreate

优点

• 非常简单。
• 没有版本混合。

缺点

• ❌ 停机 – 用户会看到服务中断。

何时使用

• 单实例应用。
• 开发 / 测试环境。
• 无法同时运行多个版本的应用。

---

蓝绿

它是什么
维护两个环境：

• Blue – 当前版本。
• Green – 新版本。

流量瞬间从蓝切换到绿。

实现方式

1. 将新版本部署到一组独立的 Pod（green）。
2. 更新 Service 选择器（或 Ingress）指向 green Pod。

优点

• 即时回滚。
• 无停机。
• 非常安全的部署方式。

缺点

• 两个环境同时存在时需要双倍资源。
• 通常是手动或工具驱动。

何时使用

• 高风险发布。
• 关键生产系统。

---

金丝雀

它是什么
新版本先向少量用户发布，然后逐步增加流量。

实现方式

• 为金丝雀版本部署更少的副本，或
• 通过 Ingress 或 Service Mesh 进行流量分割。

优点

• 风险极低；可以提前发现 bug。

缺点

• 设置更复杂。
• 需要监控和指标。

何时使用

• 大规模用户群。
• 对性能敏感的应用。

---

A/B 测试

它是什么
根据请求头、Cookie 或地区向不同用户提供不同版本。

优点

• 支持业务实验和功能对比。

缺点

• 设置复杂。
• 并非纯粹的“部署”策略。

何时使用

• 功能测试。
• 产品实验。

---

策略对比