滚动/蓝绿/金丝雀发布

写完代码只是第一步，把它安全地上线才是真考验。直接把旧版本全换掉，一旦新版本有 bug，全站就黑了。Kubernetes 给了你几种”渐进式上线”的姿势，风险从低到高、操作从简到繁，我们一个一个看。

先记住一条：不管哪种策略，Service 的 selector 决定了哪批 Pod 能接到流量。所谓”切换流量”，本质就是让 Service 或 Ingress 把请求指向不同的 Pod 集合。滚动发布靠控制器自己换，蓝绿和金丝雀靠你手动/工具切 Service 和 Ingress。

50-1 滚动发布（Rolling Update）

这是最常用、也是 Kubernetes 最”原生”的方式。Deployment 默认就是滚动发布，不需要你额外装任何东西。

原理很简单：新副本一个个起来，旧副本一个个退场，中间始终有一部分 Pod 在干活，所以服务不中断。你在 spec.strategy.rollingUpdate 里控制节奏：

spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # 最多比期望多 1 个 Pod（扩出来顶上）
      maxUnavailable: 0  # 最多允许 0 个不可用（保证容量不降）

maxSurge 控制”最多多几个”，maxUnavailable 控制”最多少几个”。比如 4 个副本、maxSurge:1, maxUnavailable:0，那就是先起 1 个新的、再退 1 个旧的，滚动往前推。

滚动发布的缺点：新旧版本同时在跑，如果你的数据库 schema 不兼容新旧两端，就会出错。而且它没法”只让一小撮用户试新版本”，是所有流量一起渐变。

50-2 蓝绿发布（Blue-Green）

蓝绿的核心思想：准备两套完全一样的环境，一套跑旧版（蓝），一套跑新版（绿）。流量一开始全在蓝。等绿的就绪且验证 OK，把 Service 的 selector 一改，瞬间把所有流量切到绿。出问题？再把 selector 改回蓝，秒级回滚。

# 蓝（旧版）和绿（新版）是两个独立的 Deployment
# 流量由 Service 的 selector 决定走向
apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  selector:
    app: web
    version: green   # 改这一行：blue <-> green 即可切流
  ports:
  - port: 80
    targetPort: 8080

优点很明显：

• 切换是原子的，没有”滚到一半”的中间态。
• 回滚极快，改回 selector 即可，不用等 Pod 重建。

代价是：同一时刻你要养两套环境，资源开销翻倍。而且切换瞬间，蓝上还在处理中的请求会被切断（除非你做了优雅退出）。

50-3 金丝雀发布（Canary）

金丝雀名字来自矿工带金丝雀下井测毒气：先放一小撮，活着再放大。发布时，你让极少部分流量先打到新版本，大部分还走旧版。观察新版的指标（错误率、延迟、日志）没问题，再逐步把比例放大到 100%。

在纯 Kubernetes 原语里，金丝雀可以这样拼：

• 新旧两个 Deployment 同时跑。
• Service 的 selector 同时匹配两者（比如都带 app: web），但旧版副本多、新版副本少。因为 Service 对端点做负载均衡，新版 Pod 少，自然只分到少量流量。

# 旧版 9 个副本，新版 1 个副本，Service 同时选中二者
# 大约 10% 的流量会落到新版——这就是"金丝雀"
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-stable
spec:
  replicas: 9
  selector:
    matchLabels: {app: web, track: stable}
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-canary
spec:
  replicas: 1
  selector:
    matchLabels: {app: web, track: canary}

想更精细地按”百分比”切流（比如先 5% 再 20% 再 50%），光靠副本比例就不够准了。这时要借助 Ingress 控制器（如 Nginx Ingress 的 canary 注解）或服务网格（Istio），按权重把流量按比例导到新版本。这属于进阶玩法。

50-4 三种策略怎么选

一张表对比清楚：

策略	资源开销	回滚速度	流量精度	适合场景
滚动	低（略多副本）	中（需重建）	全部渐变	日常小版本、兼容性强
蓝绿	高（双倍）	极快（切 selector）	全量切换	不兼容大改、要秒回滚
金丝雀	中（少量额外）	快（调比例/selector）	可控百分比	新功能试水、降风险

选择口诀：日常小改上滚动；不兼容大改要秒回滚上蓝绿；想让真实用户先帮你试新功能上金丝雀。

50-5 进阶工具一句话

原生 YAML 能拼出三种策略的雏形，但要做到”按百分比精准切流 + 自动按指标推进 + 失败自动回滚”，还得靠专门工具：

• Argo Rollouts：把金丝雀/蓝绿做成 Kubernetes 原生 CRD，支持按步长、按分析结果自动推进。
• Flagger：基于指标的渐进式交付，常配合 Istio/Linkerd 做自动金丝雀。
• 服务网格（Istio 等）：提供细粒度流量权重，是精准金丝雀的底座。

小结

发布策略本质是”在多大范围内、多快地把流量交给新版本”：

1. 滚动发布最原生，新旧交替、不中断，但版本需兼容。
2. 蓝绿发布双环境瞬间切换，回滚快但费资源。
3. 金丝雀发布先放小流量试水，最稳但原语下精度有限。
4. 要精准百分比切流，得靠 Ingress/服务网格或 Argo Rollouts 这类工具。

下一章我们看：升级节点、腾空节点时，怎么保证”同一时间不能挂太多 Pod”——这正是 Pod 中断预算（PDB）的活儿。