3. 灰度迁移概念
灰度迁移是集群升级过程中控制风险、保障业务连续性的核心策略。本节从定义出发，厘清灰度发布、灰度迁移与蓝绿部署、金丝雀发布的区别，并明确灰度迁移在集群升级中的具体角色。
3.1 什么是灰度发布
灰度发布（Gray Release / Canary Release）是一种渐进式上线策略：新版本先在一小部分用户或实例上生效，观察稳定性和性能指标后，再逐步扩大范围，直至全量覆盖。其核心目标是以最小爆炸半径验证变更的正确性。
灰度发布三要素：
- 灰度批次：每次升级的实例比例（如 10% → 30% → 100%）。
- 观测窗口：每批次升级后的等待时间，用于收集指标和告警。
- 回滚条件：触发回滚的阈值（如错误率 > 1%、P99 延迟 > 500ms）。
3.2 灰度迁移与蓝绿部署/金丝雀发布的区别
三种策略常被混淆，但它们在基础设施占用、切换粒度、回滚速度上有本质差异。下表从关键维度进行对比：
| 维度 | 蓝绿部署 | 金丝雀发布 | 灰度迁移 |
|---|---|---|---|
| 基础设施 | 两套完整环境（蓝/绿） | 共享环境，新版本少量实例 | 共享环境，按比例逐步替换 |
| 切换粒度 | 全量切换（路由层面） | 小比例流量（如 5%） | 实例/副本比例（如 10% → 50%） |
| 回滚速度 | 秒级（路由切回） | 秒级（摘除金丝雀实例） | 分钟级（逐步回退批次） |
| 资源成本 | 高（双倍资源） | 低（少量额外实例） | 低（复用原资源） |
| 适用场景 | 关键业务、要求瞬时切换 | 功能验证、小范围测试 | 集群升级、大规模实例迁移 |
核心区别总结：蓝绿部署是“环境级”切换，金丝雀发布是“流量级”验证，灰度迁移是“实例级”渐进替换。集群升级场景下，灰度迁移是最贴合 Deployment 工作负载特性的策略。
3.3 灰度迁移在集群升级中的角色
在 Kubernetes 集群升级（如 kubelet 版本升级、节点池替换、操作系统更新）中，灰度迁移承担以下三个关键角色：
- 风险隔离器：将升级影响限制在少数节点/实例上，避免全量故障。
- 容量缓冲器：通过逐批迁移，确保集群整体容量始终满足业务水位。
- 验证加速器：每批次完成后自动触发健康检查与指标比对，缩短人工决策周期。
常见误区：灰度迁移不等于“慢慢升级”。如果没有明确的批次观测窗口和回滚条件，所谓的灰度只是“慢速全量发布”，风险并未降低。必须为每个批次定义可量化的健康指标。
3.4 灰度迁移在集群升级中的典型流程
以 Kubernetes 节点池升级为例，灰度迁移的典型执行步骤：
- 选定灰度节点池：从集群中划分出 10% 的节点作为首批升级目标。
- 驱逐与迁移：对灰度节点执行
kubectl drain，将 Pod 迁移至其他节点。 - 节点升级：完成操作系统/kubelet 版本升级，节点重新加入集群。
- 观测窗口：等待 15-30 分钟，监控错误率、P99 延迟、节点状态。
- 批次决策：指标正常则扩大至 30% → 50% → 100%；异常则触发回滚。
关键指标示例（灰度批次决策表）：
| 指标 | 正常阈值 | 警告阈值 | 回滚阈值 |
|---|---|---|---|
| Pod 错误率 | < 0.1% | 0.1% - 1% | > 1% |
| P99 延迟 | < 200ms | 200ms - 500ms | > 500ms |
| 节点 NotReady 比例 | 0% | < 5% | > 5% |
通过上述流程，灰度迁移将集群升级从“全量赌博”转变为“可观测、可控制、可回滚”的工程化操作，是 SRE 保障集群稳定性的核心手段。