📚 课程目录第2章 eBPF核心原理

2. eBPF 核心原理：程序生命周期、内核钩子、BPF 映射与验证器

在深入节点池巡检与流量可视化之前，必须理解 eBPF 的运行基石。eBPF 并非一个简单的内核模块，而是一个包含编译、加载、验证、附加、运行、卸载全生命周期的沙箱化执行引擎。本节将拆解其核心组件：程序生命周期、内核钩子（kprobe/tracepoint）、BPF 映射（Map）以及 BPF 验证器。

2.1 eBPF 程序生命周期

一个 eBPF 程序从编写到销毁，经历以下六个阶段。理解每个阶段的状态转换，是排查加载失败、性能瓶颈的关键。

阶段	状态	关键操作	常见失败原因
1. 编写	源码	使用 C/Rust 编写，包含许可证（GPL）	缺少许可证宏
2. 编译	BPF 字节码	Clang/LLVM 编译为 .o 文件	内联函数未标记 `__always_inline`
3. 加载 & 验证	内核对象	`bpf()` 系统调用，验证器检查	循环未展开、栈超限、指针泄漏
4. 附加	挂载到钩子	通过 `perf_event_open` 或 libbpf 附加	内核版本不匹配、钩子不存在
5. 运行	事件驱动	内核事件触发，执行字节码	Map 空间不足、权限拒绝
6. 卸载	销毁	关闭 fd 或使用 `BPF_PROG_DETACH`	引用计数未归零

运维提示： 在 Helm 部署的节点池中，eBPF 程序通常以 DaemonSet 形式运行。Pod 重启会导致程序自动卸载并重新加载。若验证器失败，Pod 会进入 CrashLoopBackOff，此时应检查内核版本与 bpftool prog list 输出。

2.2 内核钩子：kprobe 与 tracepoint

eBPF 程序必须挂载到内核的特定事件上才能执行。最常用的两类钩子是 kprobe（动态探针）和 tracepoint（静态跟踪点）。

kprobe：动态插入，可附加到任意内核函数入口（kprobe）或出口（kretprobe）。灵活但稳定性较差（函数可能随内核版本改名）。
tracepoint：静态定义，由内核开发者预埋在关键路径（如系统调用、网络收包）。稳定且参数格式固定，是生产环境的首选。

  选型对比： 在节点池流量可视化场景中，抓取网络包应优先使用 tracepoint:net:netif_receive_skb 和 tracepoint:net:napi_gro_receive_entry，而非 kprobe 到 __netif_receive_skb_core，以避免因内核函数内联导致的兼容性问题。

2.3 BPF 映射（Map）

BPF 映射是 eBPF 程序与用户空间交换数据的核心结构。它本质上是一个键值存储，支持多种类型。在流量可视化场景中，Map 用于存储连接跟踪表、包计数器和延迟直方图。

Map 类型	键/值	典型用途	节点池巡检场景
`BPF_MAP_TYPE_HASH`	任意	通用 KV 存储	存储五元组 → 连接状态
`BPF_MAP_TYPE_ARRAY`	整数索引	固定大小计数器	每个 CPU 的包计数
`BPF_MAP_TYPE_PERCPU_HASH`	任意	无锁并发统计	每个 CPU 的连接跟踪
`BPF_MAP_TYPE_RINGBUF`	记录流	高效事件推送	向用户态推送包元数据

性能陷阱： 在 Helm 部署的节点池中，如果多个 Pod 同时写入同一个全局 Hash Map，可能触发内核锁竞争。建议使用 PERCPU_HASH 或 PERCPU_ARRAY 来避免伪共享，并在用户态聚合数据。

2.4 BPF 验证器

BPF 验证器是 eBPF 安全性的核心保障。它在程序加载时执行静态分析，确保程序不会导致内核崩溃或死循环。验证器会检查以下关键项：

控制流完整性：禁止无法到达的指令，禁止循环（除非有界且可展开）。
栈访问边界：栈大小限制为 512 字节，验证器逐条检查偏移。
指针安全：禁止指针算术泄漏内核地址，禁止未检查的空指针解引用。
辅助函数白名单：只能调用内核允许的 BPF helper 函数。

2.5 小结与节点池巡检关联

在 Helm 部署的节点池中，eBPF 程序的稳定性直接依赖于对上述原理的理解：

生命周期管理：DaemonSet 滚动更新时，需确保旧程序卸载干净，新程序通过验证器。
钩子选择：流量可视化优先使用 tracepoint，避免 kprobe 因内核函数内联导致的加载失败。
Map 设计：使用 PERCPU 类型避免锁竞争，使用 Ring Buffer 高效推送流量元数据。
验证器调试：当加载失败时，通过 bpftool prog load 的详细日志定位具体违反的规则。