2. eBPF 核心概念
在深入 Hubble 流量可视化之前，必须理解 eBPF 的底层运行机制。eBPF 并非单一技术，而是一套由程序类型、数据结构、安全校验和执行模型构成的完整体系。本章将拆解这四个核心支柱，并对比传统内核模块，帮助你建立清晰的 eBPF 知识框架。
2.1 eBPF 程序类型
eBPF 程序必须挂载到内核的特定事件点才能执行。根据挂载点和触发方式的不同，主要分为以下三类：
| 程序类型 | 挂载点 | 触发时机 | 典型用途 |
|---|---|---|---|
| kprobe | 内核函数入口/出口 | 函数被调用时 | 动态追踪内核函数、参数捕获、性能分析 |
| tracepoint | 内核静态插桩点 | 预定义事件发生时 | 系统调用追踪、网络事件、文件系统操作 |
| XDP | 网卡驱动层（最早） | 数据包到达网卡时 | 高速包过滤、DDoS 防护、负载均衡 |
选型建议： Hubble 主要依赖 tracepoint 捕获网络事件（如 skb 生命周期），因为 tracepoint 接口稳定且开销低；XDP 则用于 Hubble 的轻量级包过滤预处理，减少进入协议栈的流量。
2.2 eBPF Map：内核与用户空间的桥梁
eBPF Map 是内核中的键值存储结构，用于在 eBPF 程序之间、以及 eBPF 程序与用户空间之间共享数据。Map 的类型决定了数据组织和访问方式：
- 哈希表（BPF_MAP_TYPE_HASH）：基于键的快速查找，适合流表、连接跟踪。
- 数组（BPF_MAP_TYPE_ARRAY）：固定大小，索引访问，适合计数器、统计信息。
- 环形缓冲区（BPF_MAP_TYPE_RINGBUF）：高性能数据传递，适合将事件推送到用户空间。
- 栈/队列（BPF_MAP_TYPE_STACK / QUEUE）：LIFO/FIFO 结构，适合临时数据缓存。
Hubble 中的 Map 应用： Hubble 使用 哈希表 维护每个网络流的元数据（源/目的 IP、端口、协议、开始时间），使用 环形缓冲区 将流事件实时推送给 Hubble UI 进行可视化。
// 定义哈希表 Map，用于存储网络流信息
struct flow_key {
__u32 src_ip;
__u32 dst_ip;
__u16 src_port;
__u16 dst_port;
__u8 protocol;
};
struct flow_info {
__u64 start_time;
__u64 bytes_sent;
__u64 bytes_recv;
};
struct {
__uint(type, BPF_MAP_TYPE_HASH);
__uint(max_entries, 65536);
__type(key, struct flow_key);
__type(value, struct flow_info);
} flow_map SEC(".maps");2.3 eBPF 验证器：安全第一
eBPF 验证器是内核中的静态分析引擎，在程序加载时执行严格的安全检查，确保程序不会破坏内核稳定性。验证器主要检查：
- 控制流完整性：禁止循环（除非有界）、禁止死代码、禁止递归调用。
- 内存安全：检查指针解引用、边界访问、空指针引用。
- 栈大小限制：最大 512 字节，防止栈溢出。
- 辅助函数白名单：只能调用内核允许的辅助函数。
常见验证失败原因： 未检查 Map 查找返回值（NULL 检查）、循环次数无法静态确定、访问未初始化的栈变量。验证失败时，内核会返回具体错误码（如 -EINVAL），可通过 bpftool 查看详细日志。
2.4 eBPF 与内核模块对比
传统内核模块虽然功能强大，但安全风险高、开发周期长。eBPF 在安全性和灵活性之间取得了更好的平衡：
| 对比维度 | eBPF 程序 | 内核模块 |
|---|---|---|
| 安全性 | 验证器强制检查，不会导致内核崩溃 | 无自动检查，Bug 可导致系统宕机 |
| 开发效率 | 用户态开发，快速迭代，热加载 | 需要编译内核模块，重启或卸载复杂 |
| 性能 | JIT 编译，接近原生性能 | 直接编译进内核，性能最优 |
| 可编程性 | 受限指令集，无循环/递归 | 完全内核编程能力 |
| 内核版本兼容 | CO-RE 技术适配多版本 | 需针对特定内核版本编译 |
| 适用场景 | 观测、安全、网络策略 | 设备驱动、文件系统、调度器 |
总结： 对于网络观测和流量可视化场景，eBPF 是更优选择——它提供了足够的内核可见性，同时避免了内核模块带来的稳定性和兼容性风险。Hubble 正是基于这一理念构建的。