📚 课程目录第2章 eBPF基础回顾

2. eBPF 基础回顾：程序类型、验证器、Map、Helper 函数与 Cilium 封装

在深入 Pod 资源消耗画像之前，必须重新审视 eBPF 的核心技术组件。eBPF 并非单一技术，而是一套由 程序类型、验证器、Map 和 Helper 函数 构成的沙箱执行引擎。Cilium 在此基础上进行了深度封装，将底层 eBPF 复杂性抽象为可管理的 Kubernetes 原生资源。

2.1 eBPF 程序类型：挂载点决定能力边界

eBPF 程序必须挂载到特定的内核事件上才能触发执行。不同的程序类型决定了程序能访问的数据、能调用的 Helper 函数以及最终的返回行为。在 Pod 资源画像场景中，最常用的类型如下：

程序类型	挂载点	Pod 画像核心用途
`BPF_PROG_TYPE_KPROBE`	内核函数入口/出口	追踪系统调用耗时、内存分配路径、网络协议栈处理延迟
`BPF_PROG_TYPE_TRACING`	Tracepoints / fentry/fexit	无侵入采集容器 CPU 调度延迟、Page Cache 命中率
`BPF_PROG_TYPE_XDP`	网卡驱动层	Pod 入站/出站包速率、丢包原因、PPS 画像
`BPF_PROG_TYPE_SCHED_CLS`	TC（Traffic Control）	Pod 网络流量的字节分布、连接跟踪、重传率
`BPF_PROG_TYPE_CGROUP_SKB`	cgroup 网络钩子	按 Pod 粒度统计网络带宽使用量，实现精细化限速

选型建议： 对于 Pod 资源消耗画像，优先使用 BPF_PROG_TYPE_TRACING（fentry/fexit）替代 Kprobe，前者在 x86/arm64 上具有更低的性能开销和更稳定的 ABI，适合生产环境长期运行。

2.2 eBPF 验证器：安全沙箱的守门人

验证器是 eBPF 能够安全引入生产环境的关键。它通过两阶段检查确保程序不会破坏内核稳定性：

控制流完整性（CFI）：构建程序的有向无环图（DAG），拒绝任何循环、后向跳转或不可达指令。
指令级安全：模拟执行每条指令，检查指针算术边界、内存访问范围、Helper 函数参数类型。

在 Pod 画像场景中，验证器对 Map 访问 和 指针传递 的检查最为严格。例如，以下代码片段展示了验证器允许的合法 Map 更新模式：

struct pod_metrics *entry;
// 验证器要求 key 必须来自栈上变量或 Map 查找结果
u32 key = bpf_get_current_pid_tgid() >> 32;
entry = bpf_map_lookup_elem(&metrics_map, &key);
if (entry) {
    // 验证器确认 entry 指针非空且未逃逸
    __sync_fetch_and_add(&entry->cpu_ns, delta);
}

常见陷阱： 在 Pod 画像程序中，不要将 Map 指针存储在全局变量或函数静态变量中。验证器会拒绝此类“指针逃逸”行为，导致程序加载失败。始终通过 bpf_map_lookup_elem 在每次 BPF 程序执行时重新获取指针。

2.3 eBPF Map：内核态与用户态的数据桥梁

Map 是 eBPF 程序存储和共享数据的核心结构。在 Pod 资源消耗画像中，Map 承担着聚合指标、维护上下文和传递事件的关键角色。

Map 类型	数据结构	Pod 画像典型用法
`BPF_MAP_TYPE_HASH`	Key-Value 哈希表	以 Pod ID 或 cgroup ID 为 Key，存储累计 CPU/内存/网络统计值
`BPF_MAP_TYPE_PERCPU_HASH`	Per-CPU 哈希表	消除多核竞争，用于高频更新的 PPS、BPS 计数器
`BPF_MAP_TYPE_RINGBUF`	无锁环形缓冲区	将 Pod 的异常事件（如 OOM、TCP 重传）实时推送到用户态
`BPF_MAP_TYPE_STACK_TRACE`	栈跟踪专用	采集 Pod 内用户态+内核态混合调用栈，定位热点函数

2.4 Helper 函数：受限的内核 API 接口

eBPF 程序不能直接调用内核函数，必须通过验证器批准的 Helper 函数与内核交互。在 Pod 资源消耗画像中，以下 Helper 函数构成了采集能力的基础：

bpf_get_current_cgroup_id() — 获取当前进程所属的 cgroup ID，用于将指标关联到特定 Pod。
bpf_get_current_pid_tgid() / bpf_get_current_uid_gid() — 获取进程和用户信息，用于区分 Pod 内的不同容器或线程。
bpf_ktime_get_ns() — 获取高精度时间戳，用于计算函数执行耗时、网络延迟等。
bpf_perf_event_output() — 将结构化数据发送到用户态的 Perf Event 或 Ring Buffer。
bpf_skb_load_bytes() / bpf_skb_store_bytes() — 在 TC 或 XDP 程序中读取/修改网络包数据。

  性能要点： 在 Pod 画像的热路径中（如 XDP 处理每个网络包），优先使用 bpf_map_lookup_percpu_elem 和 bpf_ktime_get_boot_ns()（如果内核支持），前者避免跨 CPU 缓存失效，后者不受 NTP 时间调整影响。

2.5 Cilium 对 eBPF 的封装：从裸机指令到 Kubernetes CRD

Cilium 将上述 eBPF 底层细节封装为 Kubernetes 原生资源，使得开发者无需直接编写 BPF 字节码即可实现 Pod 资源消耗画像。其封装层次如下：

抽象层	Cilium 组件	对应 eBPF 底层
策略层	CiliumNetworkPolicy / CiliumClusterwideNetworkPolicy	自动生成 TC/XDP 程序实现 L3/L7 网络策略
观测层	Hubble / CiliumMonitor	封装 TRACING + RINGBUF，提供 Pod 粒度的流量和性能指标
负载均衡层	Service / Ingress / Gateway API	基于 BPF_MAP_TYPE_HASH 实现 Maglev/随机一致性哈希
自定义层	eBPF Program CRD / CiliumBGPLoadBalancer	允许用户注入自定义 BPF 程序，同时保留验证器和 Map 生命周期管理

Cilium 的 eBPF 程序管理器 负责以下关键封装：

自动验证与加载：将用户编写的 C 代码（受限的 BPF C）编译为 BPF 字节码，通过 bpftool gen object 进行预验证，再通过 Cilium Agent 加载到内核。
Map 生命周期管理：自动创建、挂载 BPF 文件系统（/sys/fs/bpf），并在 Pod 迁移或删除时清理对应的 Per-CPU 和 HASH Map。
Tail Call 编排：将多个 eBPF 程序通过 BPF_MAP_TYPE_PROG_ARRAY 串联，实现类似“函数调用”的扩展能力，避免单一程序超出验证器复杂度限制。