1. 蓝绿发布基础概念
1.1 什么是蓝绿发布
蓝绿发布（Blue-Green Deployment）是一种零停机、流量瞬时切换的发布策略。生产环境同时维护两套完全独立的集群——蓝集群（Blue）与绿集群（Green），任意时刻只有一套集群承载全部生产流量，另一套处于空闲待命状态。
- 蓝集群（当前生产）：运行当前稳定版本，承接所有用户请求。
- 绿集群（新版本）：部署新版本应用，完成内部验证与冒烟测试。
- 流量切换：验证通过后，通过负载均衡器（如 Nginx、ALB、Istio VirtualService）将流量从蓝集群瞬时全量切至绿集群。
- 快速回滚：若新版本出现异常，只需将流量切回蓝集群，回滚时间在秒级。
核心特征：两套独立环境 + 瞬时全量切换 + 秒级回滚。蓝绿发布不是“逐步替换”，而是“整体替换”。
1.2 蓝绿发布的核心目标
蓝绿发布的设计围绕四个关键目标展开，这些目标直接决定了它在生产环境中的适用场景与运维价值：
| 核心目标 | 说明 | 关键指标 |
|---|---|---|
| 零停机发布 | 用户在整个发布过程中无感知，请求不中断 | 发布期间错误率 < 0.1% |
| 瞬时回滚 | 新版本异常时，秒级切回旧版本 | MTTR < 30s（回滚时间） |
| 环境隔离 | 新旧版本完全独立，不共享运行时资源 | 无共享 Pod / 无共享数据库写连接 |
| 全量验证 | 新版本在真实生产环境中完成全量功能与压力验证 | 验证通过率 100% 后再切流 |
实践要点：蓝绿发布的核心价值在于“可预测性”——发布前绿集群已完全就绪，发布动作仅涉及流量调度，不涉及应用启动与注册，因此风险窗口极短。
1.3 蓝绿发布与传统滚动发布的区别
滚动发布（Rolling Update）是 Kubernetes 默认的更新策略，通过逐步替换旧版本 Pod 来发布新版本。两者在资源占用、发布速度、回滚能力、环境隔离等方面存在本质差异：
| 对比维度 | 蓝绿发布 | 滚动发布 |
|---|---|---|
| 环境数量 | 两套独立集群（蓝 + 绿） | 单集群内逐步替换 |
| 资源占用 | 2x 资源（发布期间） | 1x + 缓冲区（通常 25% 额外） |
| 发布速度 | 秒级（流量切换） | 分钟级（逐 Pod 替换） |
| 回滚速度 | 秒级（切回旧集群） | 分钟级（反向滚动） |
| 环境隔离 | 完全隔离（独立网络/存储/配置） | 共享集群，仅 Pod 版本不同 |
| 流量切换粒度 | 全量 / 0-100% 瞬时 | 逐步（如 10% → 50% → 100%） |
| 验证能力 | 全量生产环境验证后再切流 | 边发布边验证，部分流量可能异常 |
| 适用场景 | 核心业务、高可用要求、大版本升级 | 小版本迭代、资源受限、非关键业务 |
关键决策点：蓝绿发布并非银弹。当数据库 schema 变更不兼容时，蓝绿发布无法解决“两个版本同时操作同一数据库”的问题。此时需要配合数据库迁移策略（如扩展-迁移-收缩模式）或使用金丝雀发布进行灰度验证。
1.4 蓝绿发布的资源争抢风险预告
蓝绿发布在带来零停机与快速回滚优势的同时，也引入了显著的资源争抢风险——这也是本课程后续章节（MTTR 复盘与 HPA 参数配置）的核心背景：
- 资源翻倍压力：发布期间两套集群同时运行，总资源需求翻倍，可能触发集群资源不足。
- HPA 误判：新集群启动时 Pod 数量骤增，HPA 可能误判为流量高峰而过度扩缩。
- MTTR 延长：资源争抢导致新版本启动缓慢、健康检查超时，回滚决策窗口被压缩。
- 成本爆炸：在云原生环境中，2x 资源意味着 2x 成本，尤其在大规模集群中不可忽视。
课程预告：第 3-5 章将深入分析蓝绿发布资源争抢的 MTTR 复盘口径；第 6-10 章将给出 HPA 参数配置的最佳实践，确保蓝绿发布在资源受限场景下仍能稳定运行。