用 Service 切换实现蓝绿发布

让新版本与旧版本并存，通过一次 Service selector 变更完成流量切换，并保留旧副本以秒级回滚。

概述

滚动更新会逐步替换 Pod，一段时间内新旧版本同时提供服务。对无状态服务没有问题；但对混合版本会破坏共享状态的服务，蓝绿切换更安全，因为流量在同一时刻整体切换。代价是需要双倍容量，并且要求两个版本都能读写同一份数据。蓝绿不会消除向后兼容迁移的需求，反而让这个要求更显性。

步骤

与蓝色并存地部署绿色，并等待其完全就绪：

kubectl set image deployment/payments-green api=ghcr.io/acme/payments:1.5.0 -n prod
kubectl rollout status deployment/payments-green -n prod --timeout=180s

在真实流量进入前直接验证绿色：

kubectl port-forward svc/payments-green 8081:80 -n prod &
sleep 2
curl -fsS localhost:8081/healthz

用一次 patch 把 Service 的 selector 指向绿色：

kubectl patch svc payments -n prod --type=merge \
  -p '{"spec":{"selector":{"app":"payments","track":"green"}}}'

需要回滚时把 selector 切回蓝色：

kubectl patch svc payments -n prod --type=merge \
  -p '{"spec":{"selector":{"app":"payments","track":"blue"}}}'

验证

切换后 kubectl get endpoints payments -n prod 应立即显示绿色 Pod 的地址，端口转发与真实域名都应返回 200。回滚验证同样重要：切回蓝色后错误率应迅速恢复，绿色副本仍保留以便排查。切换期间应同时观察两条 track 的错误率与延迟，边缘指标通常比 Pod 状态更早反映问题。

注意事项

切换期间两套版本同时运行，容量成本翻倍。
数据库结构必须同时兼容两个版本，采用 expand/contract 迁移。
内存中的会话状态会在切换时丢失，需要外部化存储。
不要在切换后立即删除蓝色，保留到观察窗口结束。
长连接客户端不会立刻切换，应配合 preStop 与连接排空。