📚 课程目录第2章 eBPF技术基础

2. eBPF技术基础：回顾eBPF的工作原理、内核版本依赖、以及eBPF程序与容器运行时的交互方式

在深入节点池巡检之前，必须重新梳理 eBPF 的技术根基。eBPF 并非黑盒魔法，而是一套在内核虚拟机中安全运行沙箱程序的框架。理解其工作原理、内核版本依赖以及如何与容器运行时交互，是判断镜像中 eBPF 程序能否在新集群内核上正常工作的前提。

eBPF 程序的生命周期分为三个阶段：编写与编译、验证与加载、事件绑定与执行。其核心在于将用户态编写的字节码安全地注入内核，挂载到指定的钩子（Hook）点。

  关键流程： C 代码 → LLVM/Clang 编译为 eBPF 字节码 → bpf() 系统调用加载 → 内核验证器（Verifier）检查 → JIT 编译为本地指令 → 挂载到钩子 → 事件触发执行。

eBPF 的能力与内核版本强绑定。不同内核版本引入了不同的辅助函数（Helper）、程序类型（Program Type）和 Map 类型。容器镜像中编译的 eBPF 程序如果使用了高版本内核才支持的特性，在低版本内核上将加载失败。

内核版本	关键 eBPF 特性	对容器镜像的影响
4.4 - 4.9	基础 eBPF、kprobe、tracepoint、perf_event	大多数传统监控 Agent 兼容；不支持 BPF_PROG_TYPE_SK_LOOKUP
4.15 - 4.19	BPF_MAP_TYPE_PERCPU_ARRAY、bpf_spin_lock、bpf_probe_read_str	部分 Cilium 1.7+ 功能需要此基线；bpf_probe_read 已弃用
5.3 - 5.4	BPF_PROG_TYPE_STRUCT_OPS、BPF_MAP_TYPE_RINGBUF、bpf_tcp_ca	服务网格 Sidecar 和 Cilium 大规模部署的推荐基线
5.10 - 5.15	BPF_PROG_TYPE_LSM、BPF_MAP_TYPE_TASK_STORAGE、bpf_loop	安全策略（LSM）和高级可观测性工具依赖此版本
6.0+	BPF_PROG_TYPE_SYSCALL、bpf_dynptr、bpf_iter 增强	新一代 eBPF 工具（如 bpftrace 新特性）可能要求此版本

巡检要点： 在升级目标集群上执行 uname -r 获取内核版本，并与镜像中 eBPF 程序编译时依赖的 KERNEL_VERSION 宏或 BTF（BPF Type Format）版本进行比对。BTF 依赖从内核 5.2 开始支持，但完整功能在 5.4+ 才稳定。

在 Kubernetes 环境中，eBPF 程序通常以 DaemonSet 或 Sidecar 形式运行在容器内。其与容器运行时的交互涉及三个层面：系统调用接口、cgroup/v2 钩子、以及网络命名空间。

系统调用接口： 容器内的 eBPF 程序通过 bpf() 系统调用与内核交互。容器运行时（如 containerd、CRI-O）不会拦截此调用，但 Seccomp 策略 或 AppArmor/SELinux 可能禁止 bpf() 系统调用，导致程序加载失败。
cgroup/v2 钩子： eBPF 程序可以挂载到 cgroup 钩子（如 BPF_CGROUP_INET_INGRESS）。容器运行时通过 cgroup 管理资源，eBPF 程序借此实现容器级别的网络策略和流量控制。
网络命名空间： 每个 Pod 拥有独立的网络命名空间。eBPF 程序通过 BPF_PROG_TYPE_SCHED_CLS 或 BPF_PROG_TYPE_XDP 挂载到 veth 对或宿主机网卡，实现 Pod 间通信的转发和过滤。

兼容性验证技巧： 在目标集群节点上运行 bpftool feature probe 可以列出当前内核支持的 eBPF 特性。将此输出与镜像中 eBPF 程序使用的辅助函数和程序类型进行交叉比对，是巡检中最直接有效的验证手段。