1. 蓝绿发布概述

1.1 蓝绿发布概念

蓝绿发布(Blue-Green Deployment)是一种零停机或接近零停机的应用发布策略,其核心思想是维护两套完全独立的生产环境:蓝环境(Blue)和绿环境(Green)。在任何时刻,只有一套环境承载全部生产流量,另一套环境则处于待命或空闲状态。

当需要发布新版本时,操作流程如下:

  1. 新版本部署到当前空闲环境(例如绿环境)中。
  2. 在绿环境上执行完整的集成测试、冒烟测试或预生产验证。
  3. 验证通过后,通过负载均衡器或流量路由组件,将生产流量从蓝环境瞬间切换至绿环境。
  4. 蓝环境进入空闲状态,作为下一轮发布的回滚目标或备用环境。
关键特征:蓝绿发布的核心优势在于“瞬间切换”和“即时回滚”。如果新版本出现问题,只需将流量切回旧环境即可,回滚时间通常在秒级。
蓝绿发布核心概念图 蓝绿发布核心概念图 用户流量 负载均衡器 / 网关 蓝环境 (Blue) 当前生产版本 v1.0 承载 100% 流量 绿环境 (Green) 新版本 v2.0 当前承载 0% 流量 流量切换 瞬间将流量从 蓝环境切至绿环境 回滚同理

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"}}}'
Kubernetes 蓝绿发布典型架构图 Kubernetes 蓝绿发布典型架构图 外部用户 Ingress / Gateway Service (my-app-svc) 蓝环境 Deployment version: blue Pod (v1.0) × 3 承载 100% 流量 绿环境 Deployment version: green Pod (v2.0) × 3 承载 0% 流量 切换操作 更新 Service selector 标签 即可完成切换
网络注意事项:在蓝绿切换过程中,由于 Service 的 Endpoint 更新存在短暂延迟(通常为秒级),可能导致少量连接被路由到已终止的 Pod。建议在切换前配置 preStop 钩子和 terminationGracePeriodSeconds,确保旧 Pod 优雅退出,避免流量中断。