零停机上线的艺术：滚动更新 vs 蓝绿部署

最新推荐文章于 2025-12-19 13:27:30 发布

原创最新推荐文章于 2025-12-19 13:27:30 发布 · 351 阅读

3 ·

CC 4.0 BY-SA版权

文章标签：

#蓝绿部署 #滚动更新

一、Kubernetes 默认行为：滚动更新

Kubernetes 的 Deployment 默认策略是 滚动更新。

概念

Rolling Update 会逐个或批量替换 Pod
更新过程中始终保持部分 Pod 可用
可通过 maxUnavailable 和 maxSurge 控制更新节奏

流程示意

假设有 4 个旧版本 Pod：[A A A A]

1. 新 Pod 启动 → [A A A A] + [B]
2. 删除旧 Pod → [B A A A]
3. 持续替换 → [B B A A] → [B B B A] → [B B B B]

优点

资源开销低，不需要额外环境
原地升级，Pod 标签不变
默认即可无停机

缺点

新旧版本共存，可能出现兼容性问题（API、数据库）
回滚速度慢，需要逐个替换 Pod
在关键业务场景中，可能需要更严格的流量控制

二、蓝绿部署（Blue-Green Deployment）

蓝绿部署是一种环境隔离、流量切换的发布策略，常用于高风险或核心客户场景。

概念

同时维护两套环境：
- Blue：当前生产版本
- Green：新版本
部署和测试在 Green 完成后，通过负载均衡切换流量
出现问题时，可以秒级回滚到 Blue

流程示意

用户访问 → Blue（旧版本）

部署新版本到 Green
测试 OK → 切换流量 → 用户访问 Green
问题出现 → 切回 Blue

优点

切换瞬间完成，几乎零停机
环境完全隔离，兼容性风险低
回滚极快，适合核心客户或关键业务

缺点

资源成本高，需要两套完整环境
环境一致性要求高
数据库或状态管理复杂，需要额外策略

三、滚动更新 vs 蓝绿部署对比表

特性	滚动更新	蓝绿部署
升级方式	逐个/批量替换 Pod	切换流量到新环境
停机风险	低，但有兼容问题	极低，环境隔离
回滚速度	慢（逐个替换回旧版本）	快（流量切回旧环境）
资源成本	低	高（双环境）
适用场景	日常迭代、增量更新	核心业务、关键客户、零停机要求

四、实践建议

滚动更新适合普通迭代
- 小功能、微服务日常升级
- 配合 readinessProbe/livenessProbe 可实现真正零停机
蓝绿部署适合关键业务
- 需要极高可用性和可控回滚
- 可结合金丝雀发布（User-Tiered Canary）做分层验证
回滚策略
- 滚动更新：重新部署旧版本 Pod
- 蓝绿部署：切回负载均衡或服务网关流量
监控和指标
- API 错误率、响应延迟、核心业务指标
- 必须与发布策略联动，保证问题可快速发现

五、Kubernetes 技术实现示例

滚动更新（Deployment 默认策略）

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-service
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  selector:
    matchLabels:
      app: my-service
  template:
    metadata:
      labels:
        app: my-service
    spec:
      containers:
      - name: my-service
        image: myregistry/my-service:v2

蓝绿部署（Argo Rollouts 示例）

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: my-service-rollout
spec:
  strategy:
    blueGreen:
      activeService: my-service-blue
      previewService: my-service-green
      autoPromotionEnabled: false
  replicas: 4
  selector:
    matchLabels:
      app: my-service
  template:
    metadata:
      labels:
        app: my-service
    spec:
      containers:
      - name: my-service
        image: myregistry/my-service:v2