1. 课程导论：Service Mesh 数据面容量规划在集群升级中的重要性、课程目标与受众、整体学习路径
1.1 为什么集群升级时数据面容量规划是“生死线”
在 Kubernetes 集群升级（如 kubelet 版本升级、节点池滚动、CNI 或操作系统更新）过程中，Service Mesh 数据面（通常以 Sidecar 或 Ambient 模式运行）会经历 重启、重连、流量迁移 三个阶段。如果缺乏容量规划，极易引发以下连锁故障：
- Sidecar 启动风暴：大量 Pod 同时重启，Pilot/XDS 控制面瞬时请求量飙升，导致配置下发延迟或超时。
- Envoy 内存超限：升级期间集群内端点变更频繁，Envoy 的 CDS/EDS 缓存膨胀，触发 OOMKill。
- 连接池耗尽：旧 Pod 驱逐与新 Pod 创建之间的连接迁移，导致上游连接池瞬间打满，请求失败。
- 控制面级联过载：数据面重连风暴反压控制面，造成 Pilot 或 Istiod 不可用，进而影响整个网格。
核心观点： 集群升级不是单纯的基础设施操作，而是一次对 Service Mesh 数据面弹性与容量的“压力测试”。没有容量规划的升级，等同于在生产环境做混沌工程。
1.2 课程目标与受众
| 维度 | 详细说明 |
|---|---|
| 课程目标 |
|
| 目标受众 |
|
| 前置知识 |
|
1.3 整体学习路径
本课程共 30 章，按“认知 → 评估 → 规划 → 执行 → 复盘”五个阶段组织。下图展示了完整的学习路径与章节映射关系：
1.4 课程核心交付物一览
完成本课程后，您将获得以下可直接用于生产环境的产出物：
| 交付物 | 形式 | 适用场景 |
|---|---|---|
| 数据面容量评估模型 | Excel / Python 脚本 | 升级前快速估算所需资源 |
| Sidecar 压测方案 | YAML + 脚本 | 在预发环境获取容量基线 |
| 滚动升级策略配置 | Kubernetes Operator / Helm Chart | 生产集群升级执行 |
| 监控告警规则集 | Prometheus + Grafana 配置 | 升级期间实时观测数据面健康度 |
| 升级复盘模板 | Markdown 文档 | 团队知识沉淀与持续改进 |
学习建议： 建议在阅读每章时，同步打开一个测试集群（如 Kind 或 Minikube）进行实操验证。本课程提供的压测脚本与配置模板均可在
examples/ 目录下找到。