2. 核心概念：灰度集群、基线集群、生产集群的定义与关系
在集群升级治理中，灰度集群、基线集群与生产集群是三个核心概念，它们共同构成了“小范围验证 → 基准对比 → 全量发布”的升级安全防线。理解三者的定义与关系，是执行灰度回归检查的前提。
2.1 三种集群的定义
| 集群类型 | 英文别名 | 定义 | 典型特征 |
|---|---|---|---|
| 灰度集群 | Canary / Shadow | 承载新版本制品（如 K8s 版本、Sidecar 版本、OS 镜像）的有限规模集群，用于在真实流量下验证升级后的功能、性能与稳定性。 | 节点数少（通常 3~10 台）、接入小比例生产流量（1%~5%）、具备快速回退能力。 |
| 基线集群 | Baseline / Reference | 保持当前稳定版本、与灰度集群拥有相同业务负载和流量特征的集群，作为灰度集群的“对照组”。 | 版本与生产集群一致、流量特征与灰度集群镜像、不参与升级变更、仅用于对比观测。 |
| 生产集群 | Production / Stable | 承载全部线上业务流量的稳定集群，是升级的最终目标环境，也是灰度验证通过后的发布终点。 | 节点规模最大、版本锁定在已验证的稳定基线、变更需经过严格的审批与窗口管控。 |
实践要点：基线集群并非必须独立部署一组物理节点。在资源受限时，可通过流量复制、请求镜像或从生产集群中划出固定比例的 Pod 作为“逻辑基线”。但无论物理还是逻辑，基线集群必须保证与灰度集群的流量特征、负载模型、依赖配置高度一致，否则对比结果无效。
2.2 三者的关系模型
三种集群构成“验证 → 对比 → 推广”的递进关系，而非简单的并列或包含。灰度集群是“探针”，基线集群是“标尺”，生产集群是“目标”。
核心关系公式：
灰度集群（新版本） vs 基线集群（旧版本） → 回归检查通过 → 灰度集群升级为新的生产集群基线 → 全量生产集群滚动升级。
灰度集群（新版本） vs 基线集群（旧版本） → 回归检查通过 → 灰度集群升级为新的生产集群基线 → 全量生产集群滚动升级。
2.3 灰度回归检查中的角色分工
在制品库发布窗口内，三种集群承担不同的检查职责：
- 灰度集群：执行功能回归、性能回归、安全扫描、配置校验，输出“是否通过”的初步结论。
- 基线集群：提供对比基线数据，包括 P99 延迟、错误率、CPU/内存水位、慢查询数量等，帮助判断灰度集群是否存在退化。
- 生产集群：作为最终发布目标，在灰度回归通过后，按照滚动策略逐步替换为灰度集群已验证的新版本。
常见误区：不要将“灰度集群”与“预发集群”混为一谈。预发集群通常使用模拟流量或脱敏数据，而灰度集群必须接入真实生产流量（即使比例很小），否则无法暴露真实环境下的兼容性、限流、依赖超时等问题。基线集群的存在正是为了区分“升级带来的变化”与“业务自身波动”。
2.4 三种集群的版本生命周期
在一次完整的升级发布中，三种集群的版本状态遵循以下演进路径：
- 初始状态：生产集群 = 基线集群 = 版本 V1；灰度集群 = 版本 V2（待验证）。
- 灰度验证中：灰度集群运行 V2，基线集群保持 V1，生产集群保持 V1。回归检查工具持续采集两组指标。
- 灰度通过：基线集群升级为 V2（成为新的基线），灰度集群任务完成，可回收或转为下一轮灰度。
- 全量发布：生产集群按批次滚动升级至 V2，此时生产集群 = 基线集群 = 灰度集群（V2）。
2.5 关键设计原则
- 隔离性：灰度集群与生产集群之间必须存在明确的流量隔离边界（如 DNS 权重、Ingress 路由规则、服务网格流量分割），防止灰度故障扩散至全量业务。
- 一致性：基线集群的硬件规格、内核参数、依赖中间件版本、业务代码分支必须与生产集群保持一致，否则对比结果不可信。
- 可观测性：三种集群必须接入统一的监控、日志、链路追踪体系，确保回归检查工具能无差别采集和聚合指标。
- 自动化：灰度集群的创建、流量接入、回归检查、回退、销毁应尽可能通过 CI/CD 管道自动化完成，减少人工操作引入的变量。
一句话总结：灰度集群负责“探路”，基线集群负责“标尺”，生产集群负责“承接”。灰度回归检查的本质，就是通过灰度与基线的对比，回答“新版本是否可以在生产集群上安全运行”这一核心问题。