本文目录导读:

- 核心思想:将逻辑注入内核
- 流程详解:从 Pod 到 Pod 的网络包如何被 eBPF 处理
- 关键 eBPF 挂钩点与 Cilium 的功能映射
- Cilium 通过 eBPF 实现的具体网络能力
- 总结:为什么 Cilium + eBPF 比传统方案好?
Cilium 是一个基于 eBPF (extended Berkeley Packet Filter) 的云原生网络、安全、可观测性解决方案,它利用 eBPF 的强大能力,完全在内核空间中处理网络数据包,从而绕过了传统的网络栈(如 iptables、ipvs),实现了高性能、低延迟的网络转发和安全策略。
下面我将分步骤、由浅入深地解释 Cilium 是如何利用 eBPF 实现网络功能的。
核心思想:将逻辑注入内核
传统网络如 Calico、Flannel 通常依赖 Linux 内核的 netfilter(iptables)或路由子系统,Cilium 的做法完全不同:
Cilium 编写 eBPF 程序,并将其动态加载到内核的网络数据通路(如网卡驱动、tc ingress/egress、XDP)中。 数据包到达网卡后,直接在 eBPF 程序中被处理,无需进入用户空间,也不需要遍历 iptables 规则链。
流程详解:从 Pod 到 Pod 的网络包如何被 eBPF 处理
假设有两个 Pod:Pod A(在 Node 1 上,IP: 10.0.1.2)发数据给 Pod B(在 Node 2 上,IP: 10.0.2.3)。
第一步:数据包离开 Pod A
- 触发 eBPF 程序:当 Pod A 的 veth 对中的一端(容器端)将数据包发到另一端(宿主机端)时,Cilium 在宿主机端的 veth 接口上挂载了 tc egress (Traffic Control 出口) 或 XDP eBPF 程序。
- 查找路由/端点信息:eBPF 程序会查询一个由 Cilium 维护的内核 eBPF Map。
- Map 是什么:eBPF Map 是一种键值存储结构,eBPF 程序和用户空间程序都可以读写,Cilium 将 Pod、Service、节点等信息保存在多个 Map 中。
- 查找目标:eBPF 程序提取数据包的目标 IP 地址
0.2.3,在cilium_lb(负载均衡)和cilium_endpoint(端点)等 Map 中查找。 - 判断目标:发现目标是一个远端节点上的 Pod(不在本机)。
- 封装隧道或直接路由:
- 直接路由模式:eBPF 程序直接修改数据包的源 MAC 为宿主机物理网卡 MAC,目标 MAC 为下一跳网关或目标节点物理网卡的 MAC,然后直接通过宿主机原始路由发送。
- 隧道模式:eBPF 程序会进行 VXLAN/Geneve 封装,将原始数据包(10.0.1.2 -> 10.0.2.3)封装在一个新的 UDP 包中,外层 IP 是 Node 1 -> Node 2,最终数据包被发出。
第二步:数据包穿越网络
这个封装包在物理网络中传输,和普通 UDP 包没有区别。
第三步:数据包到达 Node 2
- 触发 eBPF 程序:数据包到达 Node 2 的物理网卡,Cilium 在物理网卡上挂载了 XDP 或 tc ingress eBPF 程序。
- 解封装(如果是隧道模式):eBPF 程序识别出 VXLAN/Geneve 包头,将其剥离,恢复出原始的数据包(10.0.1.2 -> 10.0.2.3)。
- 查找本地端点:eBPF 程序再次查询 eBPF Map,发现目标 IP
0.2.3属于本机上的 Pod B。 - 绕过内核网络栈:eBPF 程序直接将数据包重定向到 Pod B 所连接的 veth 对的宿主机端,并通过该 veth 对进入 Pod B 的网络命名空间,这个过程完全绕过了 Node 2 主机上的路由、iptables、netfilter 等传统路径。性能提升的关键点就在这里。
关键 eBPF 挂钩点与 Cilium 的功能映射
Cilium 在不同的网络层级挂了不同的 eBPF 程序,实现不同的功能:
| 挂钩点 (Hook) | 位置 | 实现的核心功能 |
|---|---|---|
| XDP (eXpress Data Path) | 网卡驱动层,数据包刚进入系统 | 高性能 DDoS 防护、负载均衡(Maglev/DSR)、防火墙,因为这是最早触及数据包的地方,性能极高。 |
| TC (Traffic Control) Ingress | 网络协议栈入口,在 __netif_receive_skb_core 附近 |
用于网络策略、L3/L4 防火墙、服务转发、隧道封装/解封,这是最常用的挂钩点,用于所有进入 Pod 或 Node 的流量。 |
| TC Egress | 网络协议栈出口,在 dev_queue_xmit 附近 |
用于 Pod 出口流量策略、CNI 网络连通性、隧道封装。 |
| cgroup/sock | socket 操作(bind, connect, sendmsg 等) | 用于服务网格 (Service Mesh) 的透明代理(Sidecar-less)、DNS 安全策略,可以在进程发起连接时,直接修改 socket 的目标地址,实现负载均衡。 |
| Kprobe/Uprobe | 内核/用户函数动态跟踪 | 可观测性,Cilium 通过 kprobe 监控内核网络函数(如 tcp_connect),可以零成本地获取网络连接数据(TCP 延迟、RTT、丢包等)。 |
| Tracepoint | 内核静态跟踪点 | 可观测性,用于监控如 sys_enter_connect 等系统调用,生成 Hubble 可见的网络流日志。 |
Cilium 通过 eBPF 实现的具体网络能力
-
Pod 网络 (CNI)
- 通过 eBPF 为每个 Pod 分配 IP,并在 veth 对宿主机端挂载 eBPF 程序。
- 实现跨节点网络:eBPF 程序自动处理路由或 VXLAN/Geneve 封装,性能远超
vxlan内核模块 +iptables的方式。
-
服务负载均衡 (kube-proxy replacement)
- Cilium 完全替换 kube-proxy,它在
XDP或tc ingress挂钩点上运行 eBPF 程序。 - 当集群内一个 Pod 访问
ClusterIP(如96.0.1:443)时:- 不像 iptables 那样遍历成千上万条规则,eBPF 程序通过一个哈希查找 (O(1) 复杂度) 在
cilium_lbeBPF Map 中找到后端 Pod IP。 - DSR (Direct Server Return):Cilium 支持 DSR,让回应数据包直接回给客户端,不经过负载均衡器节点,进一步减少路径和延迟。
- Maglev:Cilium 使用 Google 的 Maglev 一致性哈希算法进行负载均衡选择后端,连接持久性好,后端变更时影响小。
- 不像 iptables 那样遍历成千上万条规则,eBPF 程序通过一个哈希查找 (O(1) 复杂度) 在
- Cilium 完全替换 kube-proxy,它在
-
网络策略 (NetworkPolicy / CiliumNetworkPolicy)
- L3/L4 策略:eBPF 程序在数据包路径上精确判断 src IP, dst IP, proto, port,由于是在内核中执行,执行效率远高于 iptables。
- L7 策略:Cilium 在 Pod 侧通过
cgroup/sock挂钩点,或者通过 Envoy proxy(Cilium 2.x 开始集成)实现对 HTTP、gRPC、Kafka 等应用层协议的深度检查,纯 eBPF 做 L7 策略能力有限,Cilium 结合了 eBPF 的高效转发 + Envoy 的 L7 处理。
-
透明加密 (WireGuard)
Cilium 通过 eBPF 将 WireGuard 集成到数据路径中,eBPF 程序决定哪些流量需要加密,然后直接将其重定向到 WireGuard 隧道。
-
可观测性 (Hubble)
- Cilium 可以零成本(相比于抓包)地获取一个 Pod 的全部网络流,它通过跟踪
tcp_connect,tcp_close,tcp_retransmit_skb等内核函数的 kprobe,将连接信息写入一个 per-CPU 的 event ring buffer,然后由用户空间的hubble-relay读取并展示,这是 eBPF 在可观测性领域的经典应用。
- Cilium 可以零成本(相比于抓包)地获取一个 Pod 的全部网络流,它通过跟踪
为什么 Cilium + eBPF 比传统方案好?
| 特性 | 传统方案 (iptables + kube-proxy) | Cilium (eBPF) |
|---|---|---|
| 性能 | 线性遍历规则链,规则多时性能剧降,CPU 消耗高,延迟高。 | 哈希查找(O(1)),固定时间处理,CPU 消耗低,延迟低。 |
| 可扩展性 | 节点数多、Service 多时,iptables 规则爆炸(常常百万条)。 | eBPF Map 大小受限于内存,但性能线性稳定。 |
| 工作模式 | 数据包需进出用户空间代理(如 kube-proxy)进行 DNAT。 | 完全内核态处理,无需进入用户空间。 |
| 可观测性 | 数据包隐身在 iptables 和 netfilter 中,难以捕捉。 | 通过 kprobe 几乎零成本地监控内核事件,拿到全量、高保真的网络流。 |
| 透明加密 | 需要额外的隧道配置或 sidecar。 | 通过 eBPF 与 WireGuard 深度集成。 |
| 安全 | iptables 匹配规则,无法做到身份感知。 | 可以使用 Cilium Identity(基于 Pod 标签的安全 ID)进行策略匹配,无需依赖 IP。 |
| 内核兼容性 | 几乎所有 Linux 内核都支持。 | 需要较高的内核版本(5.10+)才支持全部特性。 |
一句话总结:Cilium 的 eBPF 网络就像一个运行在内核中的、高性能的、可编程的、带状态防火墙/负载均衡器,它直接操作数据包,通过内置的 Map 进行快速查找和决策,从而实现了比传统 iptables 网络方案更高的性能、更强的可扩展性和更丰富的可观测性。