4、数据传输路径全景：Pod到Pod、Pod到Service、Pod到外部网络的完整数据流与eBPF挂钩点
在Cilium与Operator集成的环境中，理解数据包的完整流转路径是性能调优的基础。本章将逐一拆解三种核心通信场景：Pod到Pod、Pod到Service（ClusterIP）、Pod到外部网络，并标注每个关键节点上的eBPF挂钩点（Hook Point）。掌握这些挂钩点，意味着你能够精准定位延迟、丢包或吞吐瓶颈发生在哪个内核阶段。
4.1 场景一：Pod到Pod（同节点与跨节点）
Pod到Pod通信是Kubernetes中最基础的网络模型。Cilium通过eBPF直接在内核中完成路由与转发，绕过了传统的iptables或IPVS开销。根据Pod是否位于同一节点，数据流路径存在显著差异。
4.1.1 同节点Pod通信
当源Pod与目标Pod位于同一Kubernetes节点时，数据包无需经过物理网卡，完全在节点内核内部完成转发。这是延迟最低、吞吐最高的路径。
关键路径与eBPF挂钩点：
- 源Pod cgroup/egress： 数据包从Pod的网络命名空间发出，触发
BPF_PROG_TYPE_CGROUP_SKB或BPF_PROG_TYPE_CGROUP_SOCK_OPS，执行策略检查与VXLAN/Geneve封装决策（通常同节点不封装）。 - 宿主机tc/ingress（veth对宿主机端）： 数据包到达veth对宿主机端，触发
BPF_PROG_TYPE_SCHED_CLS（tc ingress hook）。Cilium的bpf_lxc程序在此执行L3/L4转发决策，查找本地端点映射（Endpoint Map）。 - 宿主机tc/egress（目标veth对宿主机端）： 转发决策完成后，数据包被重定向到目标Pod的veth对宿主机端，触发
BPF_PROG_TYPE_SCHED_ACT（tc egress hook）。bpf_netdev程序在此执行最终的封装/解封装（如果需要）并发送到目标Pod。 - 目标Pod cgroup/ingress： 数据包进入目标Pod的网络命名空间，触发cgroup ingress hook，执行入站策略检查。
性能调优提示： 同节点通信应尽量利用Cilium的“本地路由”模式（
routing-mode: native），避免不必要的隧道封装。在eBPF挂钩点中，重点关注 BPF_PROG_TYPE_SCHED_CLS 的执行时间，它直接决定了单跳延迟。
4.1.2 跨节点Pod通信
跨节点通信需要数据包离开源节点，经过物理网络到达目标节点。Cilium在此场景下通常使用Overlay网络（VXLAN/Geneve）或直接路由（Native Routing）。
关键路径与eBPF挂钩点：
- 源Pod cgroup/egress： 同节点场景，策略检查。
- 宿主机tc/ingress（源节点veth）： 触发
BPF_PROG_TYPE_SCHED_CLS，bpf_lxc程序查找路由表，发现目标Pod不在本地，决定进行Overlay封装或直接路由。 - 宿主机tc/egress（源节点物理网卡）： 触发
BPF_PROG_TYPE_SCHED_ACT，bpf_netdev程序执行VXLAN/Geneve封装（外层UDP头+IP头），或直接路由时修改MAC地址。数据包通过物理网卡发出。 - 物理网络传输： 数据包经过交换机/路由器到达目标节点物理网卡。
- 宿主机tc/ingress（目标节点物理网卡）： 触发
BPF_PROG_TYPE_SCHED_CLS，bpf_netdev程序识别VXLAN/Geneve隧道，执行解封装，还原原始Pod IP数据包。 - 宿主机tc/egress（目标节点veth）： 触发
BPF_PROG_TYPE_SCHED_ACT，bpf_lxc程序查找本地端点映射，将数据包发送到目标Pod的veth对。 - 目标Pod cgroup/ingress： 入站策略检查。
4.2 场景二：Pod到Service（ClusterIP）
Service（ClusterIP）是Kubernetes中服务发现与负载均衡的核心抽象。Cilium使用eBPF实现高效的Service负载均衡，完全在内核中完成DNAT（目标网络地址转换）和反向SNAT，无需经过kube-proxy或iptables。
4.2.1 数据流与挂钩点
| 步骤 | 位置 | eBPF挂钩点 | Cilium程序 | 操作 |
|---|---|---|---|---|
| 1 | 源Pod cgroup/egress | BPF_PROG_TYPE_CGROUP_SKB |
bpf_lxc | 策略检查，数据包发往宿主机 |
| 2 | 宿主机 tc/ingress (veth) | BPF_PROG_TYPE_SCHED_CLS |
bpf_lxc | 识别目标IP为ClusterIP，查找Service映射 |
| 3 | 宿主机 XDP (可选) | BPF_PROG_TYPE_XDP |
bpf_xdp | 早期Service负载均衡，绕过网络栈（性能最佳） |
| 4 | 宿主机 tc/egress (veth/物理网卡) | BPF_PROG_TYPE_SCHED_ACT |
bpf_lb | 执行DNAT：将ClusterIP:Port替换为后端Pod IP:Port |
| 5 | 宿主机 conntrack | 内核conntrack + eBPF辅助 | bpf_ct | 记录连接跟踪条目，用于反向SNAT |
| 6 | 目标Pod路径 | 同Pod到Pod路径 | bpf_lxc/bpf_netdev | 数据包到达选中的后端Pod |
| 7 | 返回路径 | 宿主机 tc/ingress | bpf_lb | 执行反向SNAT：将后端Pod IP还原为ClusterIP |
关键性能陷阱： 如果启用了XDP（
loadbalancer-mode: snat 且网卡支持XDP），Service负载均衡在XDP层完成，延迟极低。但XDP模式下无法使用Maglev一致性哈希（需要tc层支持）。务必根据负载均衡算法需求选择挂钩点。
4.3 场景三：Pod到外部网络（Egress）
Pod访问外部网络（如互联网或外部数据库）时，需要经过节点SNAT（源网络地址转换），将Pod IP转换为节点IP。Cilium通过eBPF实现高效的Egress网关和Masquerading（伪装）。
4.3.1 数据流与挂钩点
- 源Pod cgroup/egress： 策略检查，数据包发往宿主机。
- 宿主机 tc/ingress (veth)：
BPF_PROG_TYPE_SCHED_CLS，bpf_lxc程序判断目标IP为非集群内地址，标记为Egress流量。 - 宿主机 tc/egress (物理网卡)：
BPF_PROG_TYPE_SCHED_ACT，bpf_netdev程序执行SNAT：将源IP从Pod IP替换为节点IP（或Egress Gateway IP）。同时记录conntrack条目。 - 物理网络： 数据包以节点IP作为源地址发出。
- 返回路径（物理网卡 ingress）：
BPF_PROG_TYPE_SCHED_CLS，bpf_netdev程序根据conntrack条目执行反向SNAT，将目标IP还原为Pod IP。 - 宿主机 tc/egress (veth)： 数据包返回源Pod。
4.4 核心eBPF挂钩点汇总
下表汇总了Cilium在三种通信场景中使用的关键eBPF程序类型及其挂钩点。理解这些挂钩点有助于在性能分析时快速定位内核函数调用栈。
| eBPF程序类型 | 挂钩点 | Cilium程序名称 | 主要功能 | 性能敏感度 |
|---|---|---|---|---|
BPF_PROG_TYPE_SCHED_CLS |
tc ingress | bpf_lxc, bpf_netdev | 入站策略、路由查找、端点映射查找 | 高（每包执行） |
BPF_PROG_TYPE_SCHED_ACT |
tc egress | bpf_lxc, bpf_netdev, bpf_lb | 出站封装、SNAT/DNAT、负载均衡 | 高（每包执行） |
BPF_PROG_TYPE_XDP |
XDP (网卡驱动层) | bpf_xdp | 早期Service负载均衡、DDoS防护 | 极高（绕过内核网络栈） |
BPF_PROG_TYPE_CGROUP_SKB |
cgroup ingress/egress | bpf_lxc | Pod级别网络策略（入站/出站） | 中（仅在cgroup边界触发） |
BPF_PROG_TYPE_CGROUP_SOCK_OPS |
cgroup sock_ops | bpf_host | Socket级别策略、带宽管理 | 低（仅在socket创建/状态变化时触发） |
4.5 性能调优关键观察点
- tc挂钩点 vs XDP挂钩点： XDP在网卡驱动层执行，延迟比tc低30%-50%，但受限于网卡驱动支持和功能集（如不支持隧道封装）。对于Service负载均衡，优先考虑XDP模式。
- conntrack表大小： 在Pod到Service和Egress场景中，conntrack条目数量直接影响性能。Cilium使用eBPF的LRU哈希表，默认大小可能不足。通过
bpf_ct_global_max_entries和bpf_ct_node_max_entries调整。 - 隧道封装开销： 跨节点通信使用VXLAN/Geneve时，MTU减少50字节（VXLAN）或更多。eBPF程序在tc egress执行封装，CPU开销与包大小相关。使用
direct-routing模式可消除此开销。 - 策略规则数量： 每个eBPF挂钩点上的策略规则（NetworkPolicy）数量影响程序复杂度。Cilium将策略编译为eBPF map，查找时间复杂度为O(1)，但map大小和更新频率仍需关注。
调优实践： 使用
cilium monitor 或 bpftrace 跟踪特定挂钩点的丢包和延迟。例如，cilium monitor --type drop 可以显示哪个eBPF程序拒绝了数据包，帮助快速定位策略或路由问题。