eBPF NetFlow 流量监控 裸机 K8s

eBPF与NetFlow实现从物理机到Kubernetes的流量监控

基于eBPF/XDP和NetFlow构建的系统，可在所有层级（从物理服务器到Kubernetes集群）提供细粒度网络遥测。它突破了传统sFlow/NetFlow的局限——如高硬件开销、采样机制以及缺乏自定义字段支持。流量通过统一的路由器-on-a-stick接口处理，使XDP能在不修改内核的前提下捕获入站数据包。

eBPF以安全且低延迟的方式在操作系统内核中运行程序，非常适合实时监控。系统按5元组（IP地址、端口、协议）、字节数和数据包数统计，并以NetFlow格式导出至采集器。

选用高性能BPF映射表

BPF映射表将统计数据存储为键值对：键为5元组，值为计数器。测试发现BPF_MAP_TYPE_HASH存在以下问题：

• 多核心并发访问时锁竞争严重。
• 竞态条件导致计数不准。

使用原子操作（__sync_fetch_and_add）可消除错误，但同步开销会显著降低性能。

改用BPF_MAP_TYPE_PERCPU_HASH后，每个CPU核心拥有独立映射表，彻底避免锁争用。聚合在用户空间完成。在100核环境下不同负载下的基准测试表明，PERCPU映射性能最优。

当映射满载（60万条5元组，6万条容量）时，BPF_MAP_TYPE_LRU_PERCPU_HASH会自动淘汰旧记录——但代价是性能下降。因此，对于快速一次性读取场景，标准PERCPU_HASH仍是首选。

// 决定写入哪个映射表
#define SHARD_COUNT 25 // 分片数量
map_hash_idx = ctx->rx_queue_index % SHARD_COUNT + shard_offset;

映射分片与多线程导出

单个承载1000万条记录的映射表成为单线程导出器的瓶颈。通过按rx_queue_index（基于RSS）拆分为25个分片，实现并行读取，处理速度提升3倍。

分片优势：

• 可扩展性：无需重启即可增加映射表。
• 并行处理：传感器可同时读取多个分片。
• 缓存效率：小映射表更易命中L1/L2缓存。

基于Go语言的传感器（使用Cilium库）利用BPF_MAP_LOOKUP_AND_DELETE_BATCH每分钟读取并清空映射表，最大限度减少溢出时的数据丢失。

采样与动态负载自适应

为平衡转发性能与可观测性需求，引入采样机制。一个二级stats_map（BPF_MAP_TYPE_HASH，max_entries=128）用于追踪各分片的包数与字节数：

struct {
    __uint(type, BPF_MAP_TYPE_HASH);
    __uint(max_entries, 128);  // 最大分片数
    __type(key, __u32);        // 分片ID
    __type(value, __u64);      // 包/字节计数
    __uint(pinning, LIBBPF_PIN_BY_NAME);
} stats_map SEC(".maps");

eBPF定时器定期计算吞吐量（包/秒），当某分片超过阈值即触发采样。定时器在数据包上下文之外运行，负责聚合数据并重置计数器，确保在流量高峰（如DDoS攻击）期间仍能保持稳定，同时保留会话级观测能力。

适配虚拟化与Kubernetes环境

该物理机架构可无缝扩展至虚拟化环境及Kubernetes集群。在K8s中，eBPF/XDP以DaemonSet形式部署，通过CNI捕获Pod间流量。分片策略自动适配节点亲和性，PERCPU_HASH与vCPU一一对应。

NetFlow导出聚合命名空间、Pod IP等元数据，显著增强微服务可观测性。

核心收获：

• PERCPU_HASH消除锁竞争，吞吐量相比HASH提升2–3倍。
• 分片通过并行化使导出速度提升3倍。
• eBPF定时器+采样机制在不牺牲转发性能的前提下实现负载自适应。
• LRU变体适用于动态变化且易溢出的场景。
• 使用Cilium库的Go传感器在高吞吐解析方面表现卓越。

— Editorial Team