📚 课程目录第2章发布流水线基础

2. 发布流水线灰度发布基础：灰度发布概念、金丝雀发布、蓝绿部署、滚动更新与灰度批次的区别

2.1 灰度发布核心概念

灰度发布（Gray Release / Canary Release）是一种渐进式的软件发布策略，其核心思想是让新版本逐步接触生产流量，而非一次性全量替换。通过控制新版本实例的占比与流量权重，在真实用户环境中验证新版本的稳定性、性能与功能正确性，从而将发布风险控制在最小范围内。

  灰度发布的核心目标：
  风险隔离：新版本仅暴露给小部分用户或流量，避免全量故障。
可观测性：在灰度期间收集指标、日志、链路追踪，快速定位问题。
快速回滚：一旦发现异常，立即将灰度实例切回旧版本，恢复时间以秒计。
数据驱动：基于真实用户反馈和业务指标（如错误率、延迟、转化率）决定是否继续放量。

在容器运行时治理中，灰度发布是风险清单留痕的关键触发点。每一次灰度批次切换，都需要记录当前批次号、实例数量、流量权重、监控指标快照以及审批人信息，形成可追溯的审计证据链。

2.2 金丝雀发布（Canary Release）

金丝雀发布是灰度发布最经典的实现模式。其名称源于“煤矿金丝雀”的典故——矿工携带金丝雀下井，一旦有毒气体泄漏，金丝雀会先于人类死亡，起到预警作用。在软件发布中，金丝雀版本（新版本）先部署到少量实例上，与旧版本共存，接收一小部分真实用户流量。

金丝雀发布的关键特征：

实例级灰度：新版本与旧版本同时运行，共享同一服务端点。
流量权重控制：通过负载均衡或服务网格（如 Istio）按比例分发流量。
自动暂停/回滚：当金丝雀实例的错误率、延迟或业务指标超出阈值时，流水线自动暂停并触发回滚。
批次渐进：典型批次序列为 1% → 5% → 20% → 50% → 100%，每批次间隔观察期（如 10 分钟）。

在容器运行时治理中，金丝雀发布的风险清单留痕需要记录：金丝雀实例的 Pod 列表、流量权重配置、监控指标基线、批次切换时间戳、审批人签名。这些数据构成发布审计的核心证据。

2.3 蓝绿部署（Blue-Green Deployment）

蓝绿部署是一种环境级切换的发布策略。它维护两套完全独立的生产环境：蓝环境（当前稳定版本）和绿环境（新版本）。发布时，先在绿环境部署新版本并完成内部验证，然后通过路由切换（如修改 DNS、负载均衡器配置）将用户流量从蓝环境瞬间切换到绿环境。

对比维度	金丝雀发布	蓝绿部署
切换粒度	实例级，逐步放量	环境级，一次性切换
回滚速度	秒级（调整权重或删除实例）	秒级（切回蓝环境）
资源成本	低（仅多部署少量实例）	高（需维护两套完整环境）
风险暴露	渐进式，风险可控	全量切换，风险集中
适用场景	高流量、高可用要求	低流量、快速切换需求

蓝绿部署在容器运行时中的风险点：切换瞬间可能导致数据库连接池、缓存预热、会话状态不一致等问题。风险清单留痕必须记录切换前后的连接数、缓存命中率、错误日志峰值，以及切换操作的审批记录。

2.4 滚动更新（Rolling Update）

滚动更新是 Kubernetes 默认的更新策略。它通过逐步替换旧版本 Pod 实例来实现发布，每次替换一个或一批 Pod，直到所有实例都更新为新版本。滚动更新不依赖流量权重控制，而是通过实例数量管理来保证服务可用性。

滚动更新的核心参数包括：

maxSurge：更新期间允许超出期望副本数的最大实例数（如 25%）。
maxUnavailable：更新期间允许不可用的最大实例数（如 25%）。
minReadySeconds：新 Pod 就绪后等待的时间，确保服务稳定。

# Kubernetes Deployment 滚动更新配置示例
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 3          # 最多同时多出 3 个 Pod
      maxUnavailable: 2    # 最多允许 2 个 Pod 不可用
  template:
    spec:
      containers:
      - name: app
        image: my-app:2.0.0
        readinessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10

  滚动更新 vs 金丝雀发布：
  滚动更新不区分新旧版本流量，所有 Pod 共享同一流量入口；金丝雀发布通过权重控制流量比例。
滚动更新无法精确控制灰度比例，只能控制实例替换速度；金丝雀发布可以精确到 1% 的流量。
滚动更新回滚速度较慢，需要重新执行替换过程；金丝雀发布可以瞬间调整权重或删除灰度实例。

2.5 灰度批次（Gray Batch）与上述策略的区别

灰度批次是发布流水线中的执行单元，它定义了每次灰度操作的具体范围、条件和验证标准。灰度批次不是一种独立的发布策略，而是对金丝雀发布、蓝绿部署、滚动更新等策略的精细化编排。

灰度批次与上述策略的核心区别如下：

概念	本质	粒度	与灰度批次的关系
金丝雀发布	流量权重控制策略	实例/流量	灰度批次可定义金丝雀的每个权重阶段（如 1% → 5%）
蓝绿部署	环境切换策略	环境	灰度批次可定义蓝绿切换前的验证步骤和切换条件
滚动更新	实例替换策略	实例	灰度批次可定义滚动更新的批次大小和暂停条件
灰度批次	发布执行单元	批次	自身是编排容器，包含策略选择、条件判断、验证步骤

2.6 总结：选择策略的决策树

在实际发布流水线中，选择哪种策略取决于业务场景和风险容忍度。以下决策树可帮助团队快速判断：

是否需要精确控制流量比例？ → 是 → 金丝雀发布 + 灰度批次
是否需要快速全量切换？ → 是 → 蓝绿部署 + 灰度批次（验证批次）
是否希望自动化程度最高？ → 是 → 滚动更新 + 灰度批次（控制 maxSurge/maxUnavailable）
是否对资源成本敏感？ → 是 → 优先金丝雀或滚动更新，避免蓝绿部署