4. 蓝绿发布原理：两套环境并行、流量切换、零停机、快速回滚
蓝绿发布（Blue-Green Deployment）是 Kubernetes 生态中最成熟、最安全的发布策略之一。其核心思想是：在生产环境中同时维护两套完全独立的版本环境（蓝环境与绿环境），通过一次性流量切换实现版本升级，而非逐步替换旧实例。这种模式天然具备零停机、瞬时回滚的能力，尤其适合对可用性要求极高的关键业务。
4.1 核心概念与两套环境模型
蓝绿发布将生产环境逻辑上划分为两个独立的“颜色”环境，每个环境都包含完整的应用栈（Service、Deployment、ConfigMap、Secrets 等）。在任何时刻，只有其中一个环境承载全部生产流量，另一个环境处于待命或空闲状态。
关键术语：
- 蓝环境（Blue）：当前正在运行的生产版本，承载 100% 用户流量。
- 绿环境（Green）：新版本部署的目标环境，部署完成后经过验证，再切换流量。
- 流量切换点：通常由 Service 的 selector 标签或 Ingress 的路由规则控制，实现瞬间切换。
- 回滚：只需将流量切回原环境，无需重新部署旧版本。
4.2 蓝绿发布的标准流程
一次完整的蓝绿发布包含以下 5 个阶段，每个阶段都有明确的验证与回滚条件。
| 阶段 | 操作 | 流量状态 | 验证点 |
|---|---|---|---|
| 1. 准备 | 确认蓝环境健康，准备绿环境资源清单（Deployment、Service、ConfigMap） | 蓝：100% / 绿：0% | 蓝环境无异常告警 |
| 2. 部署绿环境 | 在绿环境命名空间或使用不同标签部署 v2 版本 | 蓝：100% / 绿：0% | 绿环境 Pod 全部 Running |
| 3. 验证绿环境 | 通过内部端点或临时 Ingress 对绿环境进行冒烟测试、健康检查 | 蓝：100% / 绿：0% | 接口响应正常、数据库迁移兼容 |
| 4. 切换流量 | 修改 Service 的 selector 指向绿环境标签，或更新 Ingress 路由权重 | 蓝：0% / 绿：100% | 监控无 5xx 激增、延迟正常 |
| 5. 观察与清理 | 观察一段时间（如 30 分钟），确认稳定后销毁蓝环境 | 蓝：0% / 绿：100% | 业务指标符合预期 |
最佳实践：在切换流量前，建议对绿环境执行“预生产验证”，包括：接口自动化测试、数据库读写分离验证、缓存预热。切换后前 5 分钟是故障高发窗口，应开启全链路监控告警。
4.3 零停机实现机制
蓝绿发布实现零停机的关键在于：流量切换是原子操作，且两套环境在切换前都已就绪。Kubernetes 中通过 Service 的 selector 机制实现瞬时切换：
# 切换前：Service 指向蓝环境
apiVersion: v1
kind: Service
metadata:
name: my-app-service
spec:
selector:
app: my-app
version: v1 # 蓝环境标签
ports:
- port: 80
targetPort: 8080
# 切换时：只需将 version 改为 v2
# kubectl patch service my-app-service -p '{"spec":{"selector":{"version":"v2"}}}'
# 该操作在 Kubernetes 控制平面内完成，毫秒级生效切换过程中，Kubernetes 的 kube-proxy 会更新所有节点的 iptables/IPVS 规则，新连接立即路由到绿环境 Pod。已建立的旧连接（长连接）会继续由蓝环境处理直至自然断开，从而实现连接级别的平滑过渡。
4.4 快速回滚策略
蓝绿发布的回滚速度是所有发布策略中最快的——无需重新部署，只需再次切换流量。回滚触发条件通常包括：
- 错误率飙升：绿环境 5xx 错误率超过阈值（如 1%）
- 延迟异常：P99 延迟超过基线的 2 倍
- 业务指标下降：订单转化率、API 成功率等核心指标异常
- 人工决策：测试团队或 SRE 发现功能缺陷
注意：回滚前需确认蓝环境仍然健康且未被回收。如果蓝环境 Pod 已被 HPA 缩容或手动清理，回滚前需要先恢复蓝环境的副本数。建议在切换后保留蓝环境至少 30 分钟，作为回滚缓冲区。
4.5 蓝绿发布 vs 滚动更新 vs 金丝雀发布
为了帮助你在实际项目中做出正确选择，下表对比了三种主流发布策略的核心差异：
| 维度 | 蓝绿发布 | 滚动更新 | 金丝雀发布 |
|---|---|---|---|
| 资源消耗 | 高（需两倍资源） | 低（逐步替换） | 中（少量金丝雀实例） |
| 回滚速度 | 秒级（流量切换） | 分钟级（逐步回滚） | 秒级（切回主版本） |
| 零停机 | ✅ 是 | ✅ 是（需配置 PDB） | ✅ 是 |
| 流量控制粒度 | 粗粒度（0/100） | 中粒度（逐步替换） | 细粒度（1%/5%/10%...） |
| 适用场景 | 核心业务、数据库迁移、重大版本 | 常规迭代、无状态应用 | A/B 测试、灰度验证、风险控制 |
| 复杂度 | 中（环境管理） | 低（K8s 原生） | 高（需流量管理组件） |
4.6 蓝绿发布的关键注意事项
- 数据库兼容性：蓝绿环境共享同一数据库时，新版本必须向后兼容旧版本的数据库 schema 和查询。建议使用“向前兼容”的数据库迁移策略（如新增字段允许 NULL、不删除旧列）。
- 会话状态：如果应用依赖内存会话（如 Tomcat Session），切换后用户会话会丢失。解决方案：使用外部会话存储（Redis/数据库）或采用无状态架构。
- 资源成本：蓝绿发布需要两倍的计算资源。在非高峰期，可考虑将空闲环境缩容至最小副本数（如 1 个 Pod），以降低成本。
- 环境标签管理：建议使用统一的标签规范，如
environment: blue和environment: green，配合version标签实现精细化管理。 - 自动化与 CI/CD 集成：蓝绿发布应完全自动化，包括：部署绿环境、自动验证、流量切换、健康监控、自动回滚。避免人工操作引入风险。
生产案例：某金融科技公司使用蓝绿发布进行核心交易系统的版本升级。每次发布流程为：GitLab CI 构建镜像 → ArgoCD 部署绿环境 → 自动化测试套件验证（耗时 10 分钟）→ 手动确认 → Service selector 切换 → 观察 30 分钟 → 自动清理蓝环境。上线至今保持 99.99% 可用性，回滚次数 0 次。