1. 课程导论：蓝绿发布与灾备切换的背景、目标与课程整体架构
1.1 为什么需要蓝绿发布与灾备自动化？
在云原生生产环境中，应用发布与基础设施故障是导致服务中断的两大核心诱因。传统滚动更新（Rolling Update）虽然能逐步替换实例，但在版本回退速度、流量精细控制、以及跨集群灾备切换方面存在明显短板。蓝绿发布与灾备自动化故障切换正是为解决这些痛点而设计。
核心痛点： 一次错误的灰度发布可能导致全站 503；一个可用区断电可能导致整个业务集群不可用。蓝绿发布提供“瞬时切换”的发布安，灾备自动化则提供“分钟级恢复”的故障兜底能力。
1.2 蓝绿发布 vs 滚动更新 vs 金丝雀发布
| 对比维度 | 蓝绿发布 | 滚动更新 | 金丝雀发布 |
|---|---|---|---|
| 切换速度 | 秒级（Service 切换） | 分钟级（逐步替换） | 分钟级（流量比例调整） |
| 回退速度 | 秒级（切回旧 Service） | 分钟级（反向滚动） | 秒级（流量比例归零） |
| 资源占用 | 双倍（绿/蓝两套） | 1x + 缓冲 | 1x + 少量金丝雀 |
| 流量控制粒度 | 全量/全无 | 按 Pod 逐步 | 按百分比/Header |
| 适用场景 | 核心服务、数据库迁移 | 常规无状态应用 | A/B 测试、灰度验证 |
1.3 灾备自动化的关键目标
- RTO（Recovery Time Objective）< 5 分钟： 从故障发生到业务完全恢复的时间窗口。
- RPO（Recovery Point Objective）≈ 0： 数据丢失量趋近于零，依赖实时同步与持久卷快照。
- 故障自愈闭环： 无需人工介入，系统自动完成“故障检测 → 流量切换 → 健康确认 → 通知告警”全流程。
- 多集群/多可用区容灾： 支持同城双活、异地灾备等拓扑。
1.4 课程整体架构图
下图展示了本课程的知识体系与实验路径：从基础概念出发，逐步深入到蓝绿发布实现、灾备切换自动化、以及生产级最佳实践。
1.5 课程模块与实验清单
| 模块 | 核心内容 | 实验环境 |
|---|---|---|
| 模块一：基础篇 | K8s 网络模型、Service 原理、Ingress 控制器、Pod 健康检查 | Minikube / Kind |
| 模块二：蓝绿发布 | 双 Service 切换、ConfigMap/Secret 环境隔离、自动化回滚脚本 | K8s 1.28+ |
| 模块三：灾备切换 | Velero 备份恢复、ClusterAPI 多集群管理、DNS/Global Load Balancer 切换 | 双集群（云厂商 / 本地） |
| 模块四：自动化与混沌 | Argo Workflows 编排、LitmusChaos 故障注入、Prometheus + Alertmanager 联动 | 已有集群 + 监控栈 |
| 模块五：生产实战 | 成本模型、容量规划、发布工单系统集成、SLA 验证 | 生产级模拟环境 |
1.6 蓝绿发布与灾备切换的核心流程对比
下面这张 SVG 图从“发布”和“灾备”两个维度，对比了蓝绿切换与故障切换的流程差异，帮助理解两者的本质区别。
学习建议： 本课程前 5 章聚焦“蓝绿发布”的纯 K8s 原生实现，后 5 章转向“灾备自动化”的多集群编排。建议先掌握 Service 与 Ingress 的流量转发原理，再进入自动化脚本编写环节。
1.7 课程前置知识要求
- 熟悉 K8s 基本概念：Pod、Deployment、Service、Namespace。
- 具备基本的 YAML 编写与
kubectl操作能力。 - 了解 Linux 网络基础（DNS、负载均衡、TCP 连接）。
- （可选）有 CI/CD 流水线使用经验。
注意： 本课程所有实验均可在本地 Minikube 或 Kind 集群中完成，但灾备切换模块需要至少两个集群（可通过云厂商免费试用或本地虚拟机搭建）。请提前准备好集群环境。