1. 课程导论：为什么需要Pod级容量规划？
1.1 传统容量规划的盲区：从节点到Pod的粒度鸿沟
在Kubernetes集群中，传统容量规划通常以节点（Node）为最小观测单元。运维团队通过节点CPU/内存利用率、集群整体水位来评估资源是否充足。然而，这种粗粒度视角存在一个根本性问题：节点健康不等于Pod健康。
一个节点可能整体利用率仅40%，但某个关键Pod已因CPU Throttling导致延迟飙升；反之，节点利用率达到80%，但所有Pod均运行平稳。节点级指标无法反映Pod内部的资源竞争与性能瓶颈。
核心矛盾： 传统容量规划回答的是“集群够不够用”，而业务SLO要求的是“每个Pod够不够用”。两者之间存在一个粒度鸿沟。
1.2 传统HPA与VPA的局限性
Kubernetes内置的HPA（Horizontal Pod Autoscaler）和VPA（Vertical Pod Autoscaler）虽然实现了自动扩缩容，但在实际生产环境中存在显著局限：
| 维度 | HPA（水平扩缩） | VPA（垂直扩缩） |
|---|---|---|
| 观测指标 | CPU/Memory利用率（Metrics Server） | CPU/Memory历史百分位（VPA Recommender） |
| 响应粒度 | Deployment/StatefulSet级别 | Pod级别（需重建） |
| 实时性 | 分钟级（Metrics Server采集间隔+冷却时间） | 小时级（基于历史数据推荐） |
| 对突发流量的感知 | 滞后，无法捕捉微秒级CPU Burst | 不感知，仅做静态推荐 |
| 资源画像能力 | 无，仅依赖利用率阈值 | 有，但基于粗粒度历史聚合 |
| Pod内部视角 | 无，无法区分业务线程与内核开销 | 无，无法区分内存分配模式 |
典型生产案例： 某在线推理服务使用HPA，节点CPU利用率维持在60%，但Pod内因eBPF Hook和网络栈开销导致实际业务线程CPU时间片不足，P99延迟从20ms飙升至500ms。HPA完全无感知，因为节点级CPU利用率未触发阈值。
1.3 Cilium eBPF与资源画像联动的价值
Cilium基于eBPF技术，能够在内核态以极低开销捕获每个Pod的细粒度资源消耗，包括：
- CPU使用分解： 区分用户态、内核态、SoftIRQ、HardIRQ、eBPF程序自身开销。
- 内存访问模式： 缺页中断频率、TLB Miss、内存带宽占用。
- 网络I/O栈开销： 每个数据包的协议处理、Socket Buffer分配、Netfilter遍历耗时。
- 系统调用频率与分布： 哪些syscall消耗了最多CPU时间。
将这些eBPF观测数据与资源画像（Resource Profiling）技术结合，可以实现：
- Pod级真实资源需求建模： 不再依赖CPU利用率百分比，而是基于实际指令执行、内存分配、I/O等待建立资源消耗模型。
- 动态容量校准： 根据实时eBPF数据，自动调整Pod的Request/Limit，消除资源浪费与性能瓶颈。
- 预测性扩缩容： 基于资源画像的趋势分析，提前感知Pod资源耗尽风险，而非事后响应。
1.4 本课程的核心技术栈与收益
本课程将围绕以下技术栈展开，构建一套完整的Pod级容量规划校准体系：
- Cilium eBPF： 作为内核观测基础设施，提供Pod级CPU、内存、网络、系统调用的实时数据。
- 资源画像引擎： 基于eBPF数据建立Pod资源消耗的时序模型与特征画像。
- 容量校准控制器： 根据资源画像自动调整Pod资源规格，实现动态校准。
- SLO验证与回滚： 通过eBPF持续验证校准效果，异常时自动回滚。
学习收益： 掌握从“节点级粗放管理”到“Pod级精准容量规划”的完整方法论，能够独立设计并落地基于eBPF的容量校准系统，将集群资源利用率提升20%-40%，同时消除Pod级性能抖动。
1.5 课程适用人群与前置知识
| 角色 | 核心关注点 | 前置要求 |
|---|---|---|
| SRE / 平台工程师 | 集群资源利用率优化、Pod性能稳定性 | Kubernetes基础、Linux内核概念 |
| 云原生架构师 | 容量规划体系设计、eBPF技术选型 | 微服务架构、可观测性设计 |
| 性能工程师 | Pod级性能瓶颈定位、资源画像建模 | Linux性能分析工具（perf、bpftrace） |
本课程将从eBPF基础原理讲起，逐步深入到Cilium的Pod级观测能力、资源画像算法设计、容量校准控制器实现，最终完成一个生产可用的Pod级容量规划校准系统。每一章均包含可运行的代码示例与实验场景。