1. 课程导论：为什么升级前必须做网关容量规划？
Kubernetes 集群升级是平台运维中最常见、也最具风险的操作之一。许多团队将升级视为“纯控制面操作”，只关注 API Server、etcd、Controller Manager 等组件的版本兼容性，却忽略了数据平面中网关层的容量基线。这种认知偏差直接导致升级期间出现服务中断、流量超时、甚至集群雪崩。
核心观点：网关容量规划不是“锦上添花”，而是升级操作的前置必要条件。没有基线，就没有回退阈值；没有阈值，就无法判断升级是否异常。
1.1 升级失败案例：网关容量不足引发的连锁故障
以下三个真实案例来自不同行业的 K8s 生产环境，均因升级前未做网关容量规划而导致严重故障：
| 案例 | 升级场景 | 故障表现 | 根因 |
|---|---|---|---|
| 案例 A | Ingress Controller 从 Nginx 1.19 升级至 1.25 | 升级后 30 分钟内，P99 延迟从 50ms 飙升至 12s，大量 502/504 | 新版本默认开启 HTTP/2，连接复用策略变更，导致后端 Pod 连接数暴涨，NodePort 端口耗尽 |
| 案例 B | API Gateway (Kong) 从 2.8 升级至 3.4 | 升级后 5 分钟，网关 Pod 内存 OOM，触发 CrashLoopBackOff | 新版本路由表缓存算法变更，内存占用从 1.2GB 升至 4.5GB，未提前调整 limits |
| 案例 C | Service Mesh (Istio) 从 1.12 升级至 1.16 | 升级后 10 分钟，Envoy 代理 CPU 使用率打满，Sidecar 注入延迟导致新 Pod 启动失败 | 新版本 xDS 推送频率增加 3 倍，控制面与数据面之间的连接数超出预期 |
关键洞察：三个案例的共性——升级前均未建立网关容量基线（CPU/内存/连接数/QPS 的稳态值），导致无法在升级过程中通过对比基线快速识别异常，错过了 5-10 分钟的黄金回退窗口。
1.2 容量不足的典型故障模式
基于大量生产事故复盘，我们将网关容量不足引发的故障归纳为以下 6 种典型模式：
- 连接池耗尽：升级后连接复用策略或超时参数变更，导致后端连接数超过 NodePort/ClusterIP 上限，新请求被拒绝。
- 内存泄漏型 OOM：新版本引入缓存、路由表或 TLS 会话复用机制，内存占用线性增长，最终触发 Pod OOMKill。
- CPU 突发打满：升级后控制面与数据面之间的心跳/同步频率增加，CPU 使用率从 40% 飙升至 95%+，请求排队超时。
- 连接数雪崩：升级期间 Pod 滚动重启，旧连接未及时关闭，新连接持续创建，导致网关所在节点的 conntrack 表溢出。
- QPS 吞吐量下降：新版本引入额外的请求处理逻辑（如更严格的请求验证、日志记录），单 Pod 吞吐量从 5000 QPS 降至 2000 QPS。
- 健康检查误判：升级后网关的 readiness probe 或 liveness probe 行为变更，导致健康检查频繁失败，Pod 被反复重启。
1.3 为什么升级前必须做容量规划？
从上述案例和故障模式可以提炼出 4 个必须做容量规划的核心理由：
| 理由 | 说明 | 不做的后果 |
|---|---|---|
| 建立异常检测基准 | 升级前采集 CPU、内存、连接数、QPS、P99 延迟等指标的稳态值 | 升级后无法区分“正常波动”与“异常漂移”，错过回退窗口 |
| 验证资源预留是否充足 | 确认当前 requests/limits 能否承载新版本更高的资源消耗 | 升级后 Pod 因 OOM/CPU 节流被 Kill，引发级联重启 |
| 评估滚动升级策略 | 根据容量基线计算 maxSurge/maxUnavailable 的安全值 | 滚动升级期间流量过载，部分 Pod 被压垮后剩余 Pod 承接全部流量，雪崩 |
| 制定回退阈值 | 基于基线设定告警阈值（如 P99 延迟超过基线 2 倍即回退） | 无阈值则回退决策依赖人工经验，决策时间过长导致故障扩大 |
最佳实践：在升级前至少 7 天开始采集网关层容量数据，形成 7×24 小时的基线窗口。基线应包含业务高峰和低谷两个时段的数据，避免仅采集低峰期数据导致基线偏小。
1.4 容量规划基线构建的整体流程
本课程将围绕以下 6 个步骤展开，构建完整的网关容量规划基线：
- 指标采集：确定需要采集的网关层关键指标（CPU、内存、连接数、QPS、延迟、错误率）
- 基线计算：使用百分位统计（P50/P95/P99）和趋势分析，生成稳态基线
- 容量评估：将基线映射到当前资源规格，评估是否存在瓶颈
- 升级策略设计：根据基线制定滚动升级参数（maxSurge、maxUnavailable、Pod 优雅终止时间）
- 监控与告警配置：基于基线设置动态告警阈值，实现升级期间的自动异常检测
- 回退预案：定义回退触发条件和自动化回退流程
1.5 本章小结
升级前不做网关容量规划，本质上是将版本兼容性测试与容量验证两个风险维度混为一谈。本课程后续章节将逐一拆解上述 6 个步骤，提供可落地的指标采集模板、基线计算算法、告警阈值公式和自动化回退脚本。目标是让每一位学员在下次 K8s 升级前，都能自信地回答三个问题：
- 当前网关层的容量基线是多少？
- 升级后容量漂移是否在安全范围内？
- 何时应该触发回退？