1. 课程导论：为什么需要节点池容量规划？集群升级带来的流量峰值挑战

1.1 集群升级：一个被低估的“流量风暴”场景

在 Kubernetes 集群的日常运维中，版本升级是最常见但风险最高的操作之一。当集群控制面或数据面组件（如 kubelet、kube-proxy、CNI 插件）发生版本变更时，节点需要经历“驱逐 Pod → 节点下线 → 系统组件更新 → 节点重新上线 → Pod 重新调度”的完整生命周期。这一过程会在集群内部引发剧烈的流量重分布，形成典型的“升级流量峰值”。

传统容量规划往往只关注业务高峰期的资源使用率，却忽略了升级操作本身带来的瞬时负载冲击。以下表格对比了两种场景的差异：

1.2 升级流量峰值的三大核心挑战

通过 eBPF 对真实生产环境升级过程的观测，我们发现流量峰值主要来自以下三个层面：

1. 网络栈重建风暴：节点升级时，CNI 插件（如 Calico、Cilium）需要重建所有 Pod 的网络命名空间、路由规则和 iptables/BPF 规则。在 50 节点并发升级的场景下，单节点可能瞬间产生数千条 conntrack 表项变更，导致网络延迟飙升 300% 以上。
2. 镜像拉取带宽争抢：新节点上线后，kubelet 会并行拉取 Pod 所需的容器镜像。如果节点池未预留足够的网络带宽，镜像拉取会与业务流量争抢出口带宽，造成服务响应超时。
3. API Server 请求洪峰：Pod 重新调度阶段，kube-scheduler 和 kube-controller-manager 会向 API Server 发起大量 watch/list 请求。eBPF 观测数据显示，升级期间 API Server 的 etcd 读写 QPS 可达到正常值的 5~8 倍。

1.3 节点池容量规划的核心逻辑

节点池容量规划不是简单的“多买几台机器”，而是基于升级流量峰值的精确观测，对节点池的冗余度、升级速率和资源隔离进行系统性设计。其核心逻辑包含三个步骤：

• 观测基线：通过 eBPF 采集升级过程中的网络、存储、计算资源消耗曲线，建立每个节点的“升级资源画像”。
• 建模预测：根据节点池规模、升级并发数、Pod 密度等参数，预测升级期间的最大资源需求。
• 策略配置：设置节点池的预留资源比例、PodDisruptionBudget（PDB）策略、升级最大并发数等参数。

以下 SVG 图展示了升级流量峰值的产生路径与节点池容量规划的对应关系：

1.4 传统容量规划的盲区

在引入 eBPF 之前，SRE 团队通常依赖以下方法进行容量规划，但这些方法在升级场景下存在明显缺陷：

• 基于 CPU/内存利用率的静态规划：只能反映稳态负载，无法感知网络栈重建、conntrack 表操作等内核级资源消耗。
• 基于 Prometheus 指标的阈值告警：采样间隔通常为 15~30 秒，而升级流量峰值可能仅持续 2~5 秒，极易被漏报。
• 基于经验值的冗余预留：缺乏数据支撑，要么过度预留造成浪费，要么预留不足导致升级失败。

1.5 本课程的学习路径

本课程将围绕“观测 → 建模 → 规划 → 验证”的闭环，系统讲解如何利用 eBPF 技术实现精准的节点池容量规划。以下是课程的核心知识结构：