1. 课程导论：容器网络性能瓶颈分析、缓存命中率对延迟的影响、Cilium与eBPF的定位
1.1 容器网络性能瓶颈全景分析
在云原生生产环境中，容器网络性能瓶颈通常表现为高延迟、低吞吐、CPU 开销大三大特征。传统基于 iptables 或 ipvs 的 kube-proxy 模式，在节点 Pod 数量超过 500 时，规则遍历延迟会呈指数级增长。以下表格对比了不同网络数据面在典型场景下的性能差异：
| 数据面方案 | P99 延迟 (μs) | 吞吐量 (Gbps) | CPU 开销 (核/10Gbps) | 规则更新延迟 |
|---|---|---|---|---|
| iptables (kube-proxy) | 150-300 | 2-4 | 2.5-3.5 | 秒级 (规则数 > 1000) |
| ipvs (kube-proxy) | 80-150 | 6-8 | 1.5-2.0 | 毫秒级 |
| Cilium (eBPF) | 20-50 | 10-15 | 0.5-1.0 | 微秒级 |
关键发现： 在 1000 条网络策略的集群中，iptables 的规则匹配延迟可达 300μs 以上，而 Cilium eBPF 通过哈希查找将延迟压缩到 50μs 以内，性能提升 6 倍以上。
1.2 缓存命中率对延迟的影响
容器网络数据包处理路径中，缓存命中率是决定延迟的核心因素。eBPF 程序运行在内核态，其指令缓存（I-cache）和数据缓存（D-cache）的命中情况直接影响每次数据包处理的纳秒级开销。以下列表展示了缓存未命中带来的性能惩罚：
- L1 I-cache 未命中： 每次未命中增加 10-20 个 CPU 周期，eBPF 程序若超过 4096 条指令，频繁未命中会导致延迟增加 30%-50%。
- L2 缓存未命中： 在大量并发连接（如 10 万+ 并发）场景下，连接跟踪表（conntrack）的哈希桶若无法驻留 L2 缓存，每次查找延迟从 5ns 飙升到 100ns。
- TLB 未命中： eBPF map 使用大页（2MB/1GB）可减少 TLB 未命中，默认 4KB 页表在 100 万+ 条目时，TLB 未命中率可达 15%，增加 20% 的 P99 延迟。
调优方向： 通过 eBPF map 的预分配、大页内存绑定、以及 Cilium 的 BPF 指令内联优化，可以将缓存命中率从 85% 提升到 98% 以上，直接降低 P99 延迟 40%-60%。
1.3 Cilium 与 eBPF 的定位
Cilium 是一个基于 eBPF 的云原生网络、安全与可观测性项目。eBPF 提供了在内核中安全运行沙箱程序的能力，而 Cilium 则将这些能力封装为 Kubernetes 原生的 CNI、Service Mesh 和网络策略引擎。以下 SVG 图展示了 Cilium 在容器网络栈中的核心定位：
1.4 缓存命中与 eBPF 程序的关联
eBPF 程序的执行效率高度依赖 CPU 缓存行为。Cilium 在数据面中大量使用 BPF 哈希 map 和数组 map，这些数据结构的访问模式决定了缓存命中率。以下 SVG 图展示了 eBPF 程序在数据包处理路径中的缓存访问流程：
1.5 课程核心目标与学习路径
本课程将围绕以下三个核心目标展开：
- 理解缓存行为： 掌握 eBPF 程序在 CPU 缓存层次结构中的执行模型，学会使用 perf、bpftrace 等工具分析缓存命中率。
- 掌握调优方法： 通过 Cilium 的 map 预分配、大页绑定、BPF 指令内联、以及内核编译参数调整，实现 P99 延迟降低 50% 以上。
- 工程落地实践： 在真实 Kubernetes 集群中部署 Cilium，通过 eBPF 程序优化网络策略、Service Mesh 和可观测性数据面的缓存效率。