1. 蓝绿发布概述
1.1 蓝绿发布概念
蓝绿发布(Blue-Green Deployment)是一种零停机或接近零停机的应用发布策略,其核心思想是维护两套完全独立的生产环境:蓝环境(Blue)和绿环境(Green)。在任何时刻,只有一套环境承载全部生产流量,另一套环境则处于待命或空闲状态。
当需要发布新版本时,操作流程如下:
- 新版本部署到当前空闲环境(例如绿环境)中。
- 在绿环境上执行完整的集成测试、冒烟测试或预生产验证。
- 验证通过后,通过负载均衡器或流量路由组件,将生产流量从蓝环境瞬间切换至绿环境。
- 蓝环境进入空闲状态,作为下一轮发布的回滚目标或备用环境。
关键特征:蓝绿发布的核心优势在于“瞬间切换”和“即时回滚”。如果新版本出现问题,只需将流量切回旧环境即可,回滚时间通常在秒级。
1.2 与传统滚动发布的区别
滚动发布(Rolling Update)是 Kubernetes 默认的升级策略,其核心是逐步替换旧版本 Pod 实例。下表从多个维度对比两种策略的差异:
| 对比维度 | 蓝绿发布 | 滚动发布 |
|---|---|---|
| 环境数量 | 两套完整环境(蓝 + 绿) | 单套环境,逐步替换 |
| 切换方式 | 瞬间流量切换(秒级) | 逐步替换 Pod(分钟级) |
| 回滚速度 | 极快,流量切回即可 | 较慢,需反向滚动替换 |
| 资源成本 | 高,需双倍资源 | 低,仅需少量额外资源 |
| 测试验证 | 可在空闲环境充分测试 | 测试窗口有限,依赖金丝雀 |
| 流量影响 | 切换瞬间可能有微量丢包 | 逐步替换,影响范围可控 |
| 适用场景 | 关键业务、高频发布、需快速回滚 | 资源敏感、低频发布、稳定性高 |
核心差异总结:蓝绿发布以“资源冗余”换取“发布速度”和“回滚确定性”;滚动发布以“时间换资源”,适合资源受限或对发布速度要求不高的场景。
1.3 蓝绿发布在 Kubernetes 中的典型架构
在 Kubernetes 环境中,蓝绿发布通常借助 Service 的标签选择器(Label Selector)机制来实现流量切换。典型架构包含以下核心组件:
- 两套 Deployment:分别对应蓝环境和绿环境,使用不同的标签(例如
version: blue和version: green)。 - 一个 Service:作为流量入口,其
selector字段指向当前活跃环境的标签。切换时只需更新 Service 的selector。 - Ingress / Gateway:可选的外部流量入口,将域名或路由指向 Service。
- 监控与验证工具:在切换前对新环境进行健康检查和功能验证。
以下是一个典型的 Service 切换示例:
# 初始状态:Service 指向蓝环境
apiVersion: v1
kind: Service
metadata:
name: my-app-svc
spec:
selector:
app: my-app
version: blue # 指向蓝环境
ports:
- port: 80
targetPort: 8080
# 切换后:将 selector 中的 version 改为 green
# kubectl patch service my-app-svc -p '{"spec":{"selector":{"version":"green"}}}'
网络注意事项:在蓝绿切换过程中,由于 Service 的 Endpoint 更新存在短暂延迟(通常为秒级),可能导致少量连接被路由到已终止的 Pod。建议在切换前配置
preStop 钩子和 terminationGracePeriodSeconds,确保旧 Pod 优雅退出,避免流量中断。