📚 课程目录第3章升级策略总览

3. 升级策略总览：滚动更新、蓝绿部署、金丝雀发布、重建式升级的对比与适用场景

在容器运行时集群的升级实践中，选择合适的升级策略直接决定了业务的连续性与交付效率。不同的策略在风险暴露面、资源开销、回滚速度和自动化程度上存在显著差异。本节将系统对比四种主流升级模式，帮助你在不同业务场景下做出最优决策。

核心原则：没有万能的升级策略。选择的关键在于评估“业务容忍的停机时间”与“基础设施可承受的资源冗余”之间的平衡点。

3.1 四种升级策略核心对比

策略	核心机制	资源开销	回滚速度	流量切换	典型适用场景
滚动更新	逐批替换旧 Pod，保持副本数不变	低（无额外副本）	慢（需反向滚动）	渐进式，无独立流量入口	无状态微服务、内部 API、批处理任务
蓝绿部署	同时运行两套完整环境，一次性切换	高（双倍资源）	极快（切回旧环境）	瞬间切换，流量全量迁移	核心交易系统、数据库迁移、合规审计
金丝雀发布	先升级少量实例，验证后再全量	中（少量额外副本）	快（移除金丝雀）	按比例或按请求特征分流	用户面功能、A/B 测试、灰度验证
重建式升级	删除旧版本，重新创建新版本	低（无额外副本）	慢（需重建旧版本）	中断式，无流量保持	StatefulSet、有状态组件、离线批处理

  关键指标：滚动更新是 Kubernetes Deployment 的默认策略，适合大多数无状态服务；蓝绿部署适合对回滚速度有极致要求的场景；金丝雀发布是功能验证与风险控制的黄金标准；重建式升级则是有状态工作负载的无奈但必要的选择。

3.2 升级策略流程对比图

下图从实例生命周期和流量切换两个维度，直观展示四种策略的运作差异：

3.3 各策略深度解析与适用场景

3.3.1 滚动更新（Rolling Update）

Kubernetes Deployment 的默认策略。通过 maxSurge 和 maxUnavailable 参数控制更新速率，逐步替换旧 Pod。优点是资源利用率高，无需额外基础设施；缺点是回滚需要反向滚动，耗时较长，且无法精确控制流量比例。

# Deployment 滚动更新配置示例
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2        # 允许超出期望副本数的最大 Pod 数
      maxUnavailable: 1  # 允许不可用 Pod 的最大数量
  template:
    # ... Pod 模板

容量规划注意：滚动更新期间，集群需要同时运行新旧版本 Pod，导致瞬时资源消耗增加。如果 maxSurge 设置过大，可能触发集群资源不足，影响其他工作负载。建议结合 HPA（Horizontal Pod Autoscaler）和集群资源监控动态调整。

3.3.2 蓝绿部署（Blue-Green Deployment）

维护两套完全独立的环境（蓝环境运行旧版本，绿环境运行新版本）。验证通过后，通过负载均衡器一次性切换流量。回滚只需切回蓝环境，速度极快。缺点是资源成本翻倍，且数据库等有状态组件需要额外处理兼容性。

适用场景：金融核心交易、支付网关、用户认证服务等对回滚速度有严格要求的系统。
容量规划挑战：需要预留双倍资源，在非高峰期进行升级以降低成本。可结合 Cluster Autoscaler 临时扩容。
数据库兼容：通常需要数据库支持前向兼容（新版本可读写旧数据），或采用“并行双写”模式。

3.3.3 金丝雀发布（Canary Release）

先升级少量实例（如 5% 或 10%），通过监控指标和用户反馈验证新版本稳定性，再逐步扩大比例直至全量。金丝雀发布是风险控制与功能验证的最佳实践，尤其适合面向用户的交互式服务。

# 使用 Service Mesh（如 Istio）实现金丝雀流量路由
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: my-app-canary
spec:
  hosts:
  - my-app
  http:
  - match:
    - headers:
        canary:
          exact: "true"   # 按请求头分流
    route:
    - destination:
        host: my-app-v2
        weight: 100
  - route:
    - destination:
        host: my-app-v1
        weight: 90
    - destination:
        host: my-app-v2
        weight: 10

  关键指标：金丝雀发布需要完善的监控体系（错误率、延迟、业务指标）和自动化回滚机制。建议设置“金丝雀窗口期”（如 10 分钟），期间持续观察，一旦指标异常立即自动回滚。

3.3.4 重建式升级（Recreate）

先删除所有旧版本 Pod，再创建新版本 Pod。这是 Kubernetes Deployment 的另一种策略，也是 StatefulSet 的默认升级方式。优点是实现简单，无版本共存问题；缺点是升级期间服务完全不可用。

适用场景：有状态应用（数据库、缓存集群）、批处理作业、离线数据处理。
容量规划要点：重建期间需要确保集群有足够的资源快速创建新 Pod。对于 StatefulSet，需关注 PVC 的保留与重新绑定策略。
优化方向：结合 PodDisruptionBudget（PDB）控制同时中断的 Pod 数量，减少对集群稳定性的冲击。

3.4 策略选择决策树

以下决策树帮助你根据业务特征快速定位合适的升级策略：

3.5 策略组合与最佳实践

在实际生产环境中，单一策略往往无法满足所有需求。推荐采用分层组合的方式：

内部基础设施层：使用滚动更新，配合 PDB 和资源配额，保证集群稳定性。
核心业务层：使用蓝绿部署，确保关键交易不中断，回滚秒级完成。
用户交互层：使用金丝雀发布，结合业务指标（如转化率、错误率）进行灰度放量。
有状态数据层：使用重建式升级，配合备份与恢复流程，确保数据一致性。

进阶建议：在 Kubernetes 中，可以通过 Flagger、Argo Rollouts 等工具实现自动化金丝雀和蓝绿部署。这些工具内置了指标分析、自动回滚和流量管理能力，大幅降低运维复杂度。