1. 课程导论与蓝图总览：eBPF在云原生网络中的角色、租户隔离的挑战、控制平面与数据平面分离的架构模式
1.1 eBPF 在云原生网络中的核心角色
云原生网络正从传统的 内核旁路（DPDK/SR-IOV） 向 内核内可编程（eBPF） 演进。eBPF 通过在内核沙箱中安全地注入字节码，实现了对网络数据包路径的深度观测与动态控制，而无需修改内核源码或加载第三方内核模块。
| 维度 | 传统方案（iptables/OVS） | eBPF 方案（Cilium/Tetragon） |
|---|---|---|
| 观测粒度 | 五元组 + 连接跟踪 | 进程级、系统调用级、协议字段级 |
| 动态注入 | 需重启服务或重载规则 | 原子替换 BPF 程序，零中断 |
| 性能开销 | 线性匹配，高 CPU 占用 | JIT 编译，O(1) 哈希查找 |
| 安全模型 | 内核模块权限 | 验证器 + BPF 辅助函数白名单 |
关键洞察： eBPF 将网络观测点从“网卡中断上下文”下沉到“内核协议栈任意钩子点”，使得每个数据包都能携带 cgroup ID、PID、namespace 等元数据，这是实现租户级隔离观测的基础。
1.2 租户隔离的核心挑战
在多租户 Kubernetes 集群中，网络观测面临三大不可回避的挑战：
- 观测数据混叠： 所有 Pod 共享同一宿主机网络栈，传统 tcpdump 无法区分流量属于哪个租户。
- 控制平面信令风暴： 租户策略变更（NetworkPolicy 更新）会触发全量 BPF 映射重载，导致控制平面 CPU 飙升。
- 性能隔离失效： 一个租户的恶意 BPF 程序（如循环未终止）可能耗尽 BPF 复杂度预算，影响其他租户的观测路径。
避坑提示： 不要试图在数据平面内完成租户身份识别。正确的做法是在 XDP 或 TC 钩子 中仅做元数据标记（如 skb->cgroup_id），将租户映射逻辑上移到控制平面，否则会导致数据平面性能退化 30% 以上。
1.3 控制平面与数据平面分离的架构模式
本课程的核心架构模式是将 eBPF 网络观测系统拆分为两个独立的通信平面，通过 BPF Map 和 Ring Buffer 进行松耦合交互：
- 数据平面（Fast Path）： 运行在 XDP/TC 钩子中，负责零拷贝抓包、元数据标记、哈希聚合。不允许执行任何租户策略逻辑。
- 控制平面（Slow Path）： 运行在用户态守护进程（如 Cilium Agent）中，负责 BPF 程序加载、Map 更新、租户策略解析、事件上报。
1.4 通信机制与性能优化总览
本课程将围绕以下四条主线展开，每条主线对应一个独立的性能优化维度：
| 主线 | 核心机制 | 性能目标 |
|---|---|---|
| 1. 控制平面通信 | BPF Map 批量更新、bpf() syscall 批处理、Netlink 事件订阅 | 控制平面延迟 < 10ms，更新吞吐 > 100K ops/s |
| 2. 数据平面隔离 | Per-CPU Map + cgroup_id 过滤、BPF 程序复杂度预算 | 数据平面 P99 延迟 < 5μs，隔离损耗 < 3% |
| 3. 观测数据导出 | BPF Ring Buffer 背压控制、Perf Event 采样率自适应 | 事件丢率 < 0.1%，CPU 占用 < 5% |
| 4. 端到端可观测性 | eBPF + OpenTelemetry 链路追踪、Prometheus 指标暴露 | 全链路覆盖，额外开销 < 1% |
学习路径建议： 如果你对 BPF Map 的并发模型不熟悉，建议先阅读内核文档
Documentation/bpf/map_percpu_hash.rst。本课程的所有优化都建立在 Per-CPU 数据结构 之上，这是避免锁竞争的关键。
1.5 课程实验环境与工具链
所有章节的实验均基于以下标准化环境，确保结果可复现：
- 内核版本： Linux 6.6+（支持 BPF 、BPF Link、BPF Arena）
- eBPF 库： libbpf v1.4+（CO-RE 重定位）
- 观测工具： bpftool、bpftrace、perf、FlameGraph
- 多租户模拟： kind + Cilium + 自定义 NetworkPolicy
# 验证环境是否满足要求
uname -r # 应 >= 6.6
bpftool version # 应 >= 7.3
cat /proc/sys/kernel/bpf_stats_enabled # 应为 1