文章目录
- 一、iptables 在大规模集群里的天花板
- 二、eBPF 是什么：内核里的沙箱
- 2.1 从 BPF 到 eBPF
- 2.2 验证器：沙箱的核心
- 三、Cilium 数据面：怎么用 eBPF 替代 kube-proxy
- 3.1 三个挂载点
- 3.2 kube-proxy 的 iptables vs Cilium 的 eBPF
- 四、bpftrace：自定义网络诊断工具
- 4.1 为什么 bpftrace 在 CSDN 是空白
- 4.2 两个完整可运行的单行命令
- 五、Hubble：服务拓扑与流量可视化的完整实现
- 5.1 为什么需要 Cilium 专用可观测性
- 5.2 Hubble 的数据来源
- 5.3 诊断示例：某服务间调用超时
- 六、NetworkPolicy：从标签到身份
- 6.1 传统 iptables 方案的问题
- 6.2 CiliumNetworkPolicy 示例
- 七、性能对比：iptables 与 eBPF 的量级差距
- 八、小结：谁应该考虑 Cilium
核心问题：eBPF 怎么在不修改代码的前提下追踪网络流量？Cilium 凭什么能替代 kube-proxy？
一、iptables 在大规模集群里的天花板
Kubernetes 默认的 Service 负载均衡依赖 kube-proxy 在每个节点上注入 iptables 规则。节点少的时候没问题——5000 个 Pod 的集群，iptables 规则数量轻松突破 10 万条，每次 Service 变更都要全量扫描所有规则，端到端延迟从 0.5ms 跳到 15ms。
这是 iptables 的设计代价：它是通用防火墙，不是高性能负载均衡器。规则越多，查找越慢，没有例外。
Cilium 的答案是：不走 iptables，在内核里直接用 eBPF 程序处理数据包转发。把"规则匹配"变成"哈希查找"，把 O(n) 变成 O(1)。
二、eBPF 是什么：内核里的沙箱
2.1 从 BPF 到 eBPF
BPF（Berkeley Packet Filter）最初是 1992 年的一篇论文，目的是让数据包过滤不需要在内核和用户态之间来回拷贝数据。传统方案：内核把包拷给用户态，用户态过滤完再决定要不要。
BPF 的创新：在内核里运行用户提供的过滤程序，只把匹配结果返回用户态。数据包本身不离开内核。
eBPF（extended BPF，Linux 3.15+）在 BPF 基础上大幅扩展：
| 维度 | 经典 BPF | eBPF |
|---|---|---|
| 指令限制 | 512 条 | 无硬限制，受验证器限制 |
| 数据结构 | 只读寄存器 | 64-bit 通用寄存器 + 栈空间 |
| 可访问的数据 | 数据包本身 | 所有内核数据结构（sk_buff、socket、task_struct 等） |
| Map 支持 | 无 | 哈希表、数组、堆栈、环形缓冲区…… |
| 尾调用 | 无 | eBPF 程序之间互相跳转 |
| JIT 编译 | 无 | 即时编译成机器码，接近原生速度 |
2.2 验证器：沙箱的核心
eBPF 程序不能直接跑在内核里——先经过验证器（Verifier），检查三件事：
- 不崩溃：程序不能访问越界内存，不能有未初始化变量
- 有穷 loops：必须证明所有循环有限次迭代，不能写出死循环
- 不伤害内核：不能做拒绝服务攻击，不能修改内核只读区域
