1. 灰度发布概述
1.1 灰度发布定义
灰度发布（Gray Release / Canary Release）是一种渐进式的软件发布策略。其核心思想是：让新版本先在一小部分用户或流量中生效，在验证稳定性和功能正确性后，再逐步扩大范围，直至全量覆盖。整个过程如同“灰度”过渡，从黑到白中间有一个平滑的渐变带，因此得名。
在 Kubernetes 平台中，灰度发布通常通过 Service Mesh（如 Istio）、Ingress Controller（如 Nginx Ingress）、原生 Deployment + Service 的流量切分，或 Flagger / Argo Rollouts 等渐进式交付工具来实现。
关键指标：灰度发布的核心度量是 “灰度批次比例”（如 5% → 20% → 50% → 100%），以及每个批次下的 “容量基线”（即该批次实例的 CPU/Memory 水位、QPS、错误率等）。容量基线留痕正是本课程要深入的主题。
1.2 灰度发布 vs 蓝绿发布 vs 金丝雀发布
三种发布策略常被混淆，但它们的设计目标和流量切换方式有本质区别。下表从多个维度进行对比：
| 对比维度 | 灰度发布（Gray Release） | 蓝绿发布（Blue-Green） | 金丝雀发布（Canary Release） |
|---|---|---|---|
| 核心思想 | 按比例逐步切流，可回退 | 两套完整环境，瞬间切换 | 小比例试错，验证后全量 |
| 流量切换方式 | 渐进式、多批次、可暂停 | 一次性全量切换（路由/负载） | 小流量 → 观察 → 逐步放大 |
| 资源占用 | 低（复用大部分资源） | 高（需同时运行两套完整栈） | 低（仅额外运行少量新版本 Pod） |
| 回滚速度 | 快（调整流量比例即可） | 极快（切回旧环境） | 快（停止新版本流量） |
| 适用场景 | 长期迭代、A/B 测试、功能灰度 | 重大版本、数据库迁移、合规发布 | 新功能验证、性能压测、稳定性评估 |
| K8s 典型实现 | Argo Rollouts + Istio / SMI | Deployment + Service 标签切换 | Flagger + Prometheus 自动分析 |
注意：在实际工程中，“灰度发布”常被用作“金丝雀发布”的同义词。但严格来说，灰度发布是一个更宽泛的概念，金丝雀发布是灰度发布的一种具体实现模式。本课程采用广义定义：灰度发布 = 渐进式流量切换 + 可观测性 + 自动化决策。
1.3 灰度发布在 K8s 中的价值
Kubernetes 的声明式 API、弹性伸缩、服务发现和网络策略，为灰度发布提供了天然的基础设施。具体价值体现在以下四个方面：
- 降低发布风险：通过小流量验证，避免全量故障。即使新版本有 Bug，影响面也控制在灰度比例内。
- 支持精细化流量路由：基于 Header、Cookie、Region、用户 ID 等维度进行灰度，实现“内部员工先试 → 外部小范围 → 全量”的阶梯式发布。
- 与可观测性深度集成：灰度批次中的 Pod 可以携带专属标签（如
version: v2、track: canary），Prometheus 和 Grafana 可以按标签聚合监控指标，实现容量基线的实时留痕。 - 自动化回滚与暂停：结合 Flagger / Argo Rollouts，当灰度批次的错误率、延迟或 CPU 使用率超过阈值时，自动暂停或回滚，无需人工介入。
下图展示了灰度发布在 K8s 中的典型流量流转路径：
容量基线留痕的挑战：灰度批次中的 Pod 可能因资源限制被 OOMKill，或因 HPA 自动扩缩容导致基线数据不连续。本课程后续章节将详细讲解如何通过 Prometheus 历史数据 + 自定义 Metrics API + 发布流水线事件绑定，实现精准的容量基线快照。
1.4 灰度发布与容量基线的关联
在灰度发布过程中，容量基线（Capacity Baseline）是衡量每个灰度批次是否健康的关键依据。它包含以下核心指标：
- 资源指标：CPU 使用率、Memory 使用量、磁盘 I/O、网络带宽。
- 业务指标：QPS（每秒请求数）、TP99 延迟、错误率（5xx / 4xx）。
- 稳定性指标：Pod 重启次数、OOM 事件、健康检查失败次数。
当灰度批次的比例从 10% 提升到 20% 时，系统需要自动对比当前批次的容量基线与上一批次的基线，判断是否存在异常偏移。如果新版本的 CPU 使用率比旧版本高出 30%，则可能触发暂停或回滚。这就是“容量基线留痕”的核心价值——让每一次灰度决策都有数据支撑。