1. 课程导论与工程背景
1.1 K8s集群升级的痛点
Kubernetes 集群升级是平台工程中最频繁、风险最高的操作之一。根据 CNCF 年度调查，超过 70% 的团队每年至少经历 3 次以上集群版本升级，而升级过程中的网关服务中断是导致 P0 级故障的首要原因。
核心痛点清单：
- 控制面与数据面解耦不足：网关 Pod 作为集群入口，升级期间流量调度与 Pod 生命周期管理脱节。
- Pod 驱逐顺序不可控：kubelet 驱逐 Pod 时，网关 Pod 可能被优先杀死，导致全局流量中断。
- 容量预留缺失：升级窗口期未预留额外 Pod 副本，导致单点过载或连接耗尽。
- 滚动更新策略僵化：默认 maxSurge/maxUnavailable 参数未针对网关场景调优。
- 监控盲区：升级过程中连接数、QPS、错误率等关键指标缺乏实时告警。
以下表格对比了升级前后网关 Pod 的典型状态变化：
| 维度 | 升级前 | 升级中 | 升级后 |
|---|---|---|---|
| Pod 副本数 | 3（稳定） | 2~4（波动） | 3（恢复） |
| CPU 利用率 | 45% | 85%+（峰值） | 50% |
| 连接数/节点 | 1200 | 2100（超限风险） | 1100 |
| 错误率（5xx） | 0.01% | 2.3% | 0.02% |
1.2 为什么需要网关Pod容量规划
网关 Pod 是集群流量的唯一入口，其容量规划直接决定升级窗口的可用性 SLO。缺乏容量规划时，升级操作往往演变为“盲人摸象”——运维人员无法预知驱逐一个网关 Pod 后剩余 Pod 能否承载瞬时流量洪峰。
关键洞察： 升级窗口期的容量规划不是简单的“多留几个副本”，而是需要精确计算 Pod 启动时间、连接排空时间、流量重分布系数 三者之间的动态平衡。
容量规划的核心价值体现在三个层面：
- 可用性保障：确保升级期间网关服务不降级，SLO ≥ 99.95%。
- 成本控制：避免过度预留资源导致集群碎片化。
- 操作可重复：将升级流程标准化，消除人工判断偏差。
1.3 本课程目标与受众
本课程旨在建立一套可量化、可自动化、可审计的网关 Pod 容量规划方法论，帮助团队在 K8s 集群升级窗口期实现零中断交付。
重要声明： 本课程不讨论通用 K8s 集群升级流程，而是聚焦于 网关层 这一特定组件的容量规划工程实践。所有模型、公式、工具链均经过生产环境验证。
课程目标
- 掌握网关 Pod 在升级窗口期的流量模型与容量计算公式。
- 学会使用 PDB（PodDisruptionBudget）、滚动更新策略、HPA 联动 构建弹性升级方案。
- 能够编写 容量规划自动化脚本，集成到 CI/CD 流水线。
- 建立升级前后的容量验证清单，消除人为误操作风险。
目标受众
| 角色 | 前置知识 | 核心收益 |
|---|---|---|
| SRE / 平台工程师 | K8s 基础操作、YAML 编写 | 可复用的容量规划模板与自动化工具 |
| K8s 架构师 | 集群架构、网络原理 | 网关层容量模型与系统设计决策 |
| 运维负责人 | 变更管理、SLO 定义 | 升级窗口风险量化与流程标准化 |
1.4 课程工程边界
本课程聚焦于网关 Pod 这一特定组件，不涵盖以下内容：
- K8s 控制面组件（etcd、kube-apiserver）的升级策略。
- 底层节点操作系统或内核升级。
- 非网关类工作负载（如无状态微服务、批处理任务）的容量规划。
工程前提： 假设集群已部署 Ingress Controller 或 API Gateway（如 Nginx Ingress、Kong、Traefik、Envoy），且网关 Pod 以 Deployment 形式运行，具备滚动更新能力。