【Cilium / eBPF】东西向包路径：Pod→Pod 停顿点与 netfilter 旁路

前四篇分别钉了坐标系、Identity、挂载与 Map。本篇把它们串成 包路径轴 上的东西向故事：一次 Pod→Pod（及经 Service 的东西向）在 Cilium eBPF 数据面可能停在哪，以及这与「绕过 netfilter」是什么关系。南北向 NodePort/外部流量的细表留给 第 6 篇；这里只铺好共享停顿点语言。

本篇在系列中的位置

篇目	核心内容
第 4 篇 · 关键 BPF Map	查哪些表
第 5 篇 · 东西向包路径	Pod→Pod 停顿点；netfilter 旁路；为 KPR 铺路
第 6 篇 · kube-proxy 替代	ClusterIP/NodePort/外部流量路径
系列目录	全部篇目

版本锚定：Cilium v1.20.0；docs.cilium.io/en/v1.20/network/ebpf/lifeofapacket/ 与 intro/、iptables/。无真实集群则不粘贴伪造 tcpdump / Hubble 时序。

一、先钉「停顿点」而不是「更快」

东西向排障若一开始就问「eBPF 是不是比 iptables 快」，会丢掉可证伪性。本篇改问：

1. 包是否还在源 endpoint 的策略岗位上？
2. 是否在做 Service VIP → backend 的 map 查找？
3. 是否已建立 CT、后续包走快路径？
4. 同节点是否已升到 socket 直通？
5. 跨节点是否多了 overlay / 加密岗位？

官方 Life of a Packet 用三张图覆盖：Endpoint→Endpoint、Egress from Endpoint、Ingress to Endpoint。下面按东西向最常见的组合重述停顿点，并挂回五轴锚点。

二、同节点 Pod → Pod（直连 IP）

基本路径

两 Pod 在同一节点、目标是对方 Pod IP（不经 Service）时，路径直觉是：

App A → veth A → (TC/lxc egress/ingress path) → Endpoint Policy
      → redirect / local delivery → veth B → App B

Intro 中的 Endpoint Policy 对象在此执行：用身份查 policy map，决定 drop、转发本地 endpoint、送 Service 对象，或送 L7 Policy。身份来自 ipcache / 连接元数据（第 2、4 篇）。

停顿检查表：

Socket Layer Enforcement

文档明确：启用 socket 层强制时，TCP 握手仍需穿越 endpoint policy，直至 ESTABLISHED；之后同节点路径可避免在 endpoint 与 L7 之间反复跑完整策略块，消息走 socket send/recv 加速。

排障含义：

• 三次握手失败：先按策略/身份/CT 查，不要先怪「加速没开」。
• 握手成功后异常：才优先怀疑 socket 加速附着、代理、或应用本身。
• 加速是优化，不是策略的替代品——文档写加速路径仍要求策略对 socket/endpoint 映射有效。

这与 第 3 篇 的 sockops / sk_msg 岗位直接对应。

三、同节点或跨节点：经 ClusterIP 的东西向

应用连接的是 Service VIP，而不是 Pod IP。此时在 Endpoint Policy 之后（或与之协同）进入 Intro 的 Service 对象：对目的 IP（及可选端口）做 LB map 查找，选中 backend，再进入本地投递或跨节点转发。

App → (optional cgroup connect rewrite) → packets to VIP
    → Service LB map lookup → backend Pod IP/port
    → CT record → policy checks as applicable
    → local delivery OR egress to remote node

两点必须分开：

1. cgroup/socket 层转换（kube-proxy 替代常见能力）：连接建立时就把 VIP 语义接上，可能减少后续包路径上的重复工作——细节与模式矩阵见第 6 篇。
2. 包路径上的 LB 查找：即便 socket 层已参与，TC/lxc 路径上仍可能维护 Service/CT 状态以保证回程与策略一致。

失败表象对照 第 4 篇：VIP 不通优先 LB map；新建连接风暴优先 CT；策略 deny 仍走 policy map——不要用同一张「网络不好」工单覆盖三种停顿。

东西向经 Service 时，后端可能在远程节点：出站图（Egress from Endpoint）上的 overlay / 路由 / 可选加密会生效。同节点直连 IP 路径上「看不见」的税，在跨节点 Service 路径上可能突然出现——这是路径差，不是「Service 实现随机变慢」。

四、跨节点 Pod → Pod（直连 IP）

源节点 Egress 图：endpoint 策略 →（可选 L7）→（可选加密）→ overlay 或直连路由出节点。目的节点 Ingress 图：入站 →（可选解密）→ 主机/overlay 路径 → 目的 endpoint 策略 → Pod。

跨节点路径是 Identity 一致性的压力测试：源节点认为目的身份是 \(I_d\)，目的节点本地 policy map 必须已允许来源身份 \(I_s\)。分配与缓存任一端滞后，就会再现第 2 篇的拒绝窗口——只是包多走了跳数。

透明加密的税与失败模式专篇见第 9 篇；本篇只把加密标成可选停顿点，避免东西向复盘时漏层。

五、与 netfilter / iptables 的旁路关系

k8s-network/13 与 linux/ebpf-cilium 文已说明设计意图：在 hook 上完成策略、LB、CT，尽量不把关键路径建立在 netfilter 链上。Datapath Intro 与 Maps/CT 文档把 CT 实现为 BPF map，与 kube-proxy 使用的内核 conntrack 估算方式分开叙述。

必须同时记住文档的另一面（Iptables Usage）：

• 内核特性不足时，部分功能可能 legacy iptables 实现。
• 与 kube-proxy 共存时，两端都可能安装 iptables 规则；文档给出集成示意。

因此「旁路」是目标架构下的主路径描述，不是「机器上永远没有 iptables 规则」的字面保证。排障时：

站内 k8s-network/21 讨论复杂度与更新路径争论；本篇把争论落到包上：你的包是否仍经过 netfilter？ 若主路径已是 TC/XDP/cgroup，conntrack 调优思路不能照搬。

旁路还有一层运维语义：宿主机上的「传统防火墙脚本」若仍往 INPUT/FORWARD 塞规则，可能对已经不走该链的流量无效，却让人以为「已经拦截」。反过来，主机网络策略若依赖 iptables，而 Cilium 主机防火墙走另一套 BPF 岗位，两边规则会看起来重复、实际作用域不同。东西向复盘前先声明：本故障关心的是 Pod 网络命名空间路径，还是 host network / 节点保护路径。

把旁路说清楚，是为第 6 篇对比 iptables/IPVS 失败模式做准备：iptables 时代常见的「规则条数爆炸、restore 卡顿」，在 KPR 下改写为「map 满、reconcile 失败、程序替换窗口」；IPVS 时代的「调度器与连接亲和」，改写为 LB map 与 session affinity map 的容量与一致性。机制对照表在第 6 篇给出；本篇只要求读者承认状态搬家了。

六、为 kube-proxy 替代篇铺路

第 6 篇将按流量类型展开：ClusterIP、NodePort、外部流量、DSR 等。本篇先固定共享词汇：

East-west building blocks (this article)
  Identity → policy map
  Service → LB map + CT
  Hooks → TC/lxc, optional cgroup, optional XDP
  Optional → overlay, encryption, L7 Envoy

North-south / KPR specifics (next article)
  Where NodePort is answered (XDP vs TC)
  How external traffic enters the same Service object
  Interop modes with kube-proxy
  Failure modes vs iptables/IPVS

阅读建议：若当前故障是两 Pod 不通，先用本篇停顿表走查；若故障是 ClusterIP/NodePort 从节点或集群外不通，读完本篇后直接进第 6 篇，避免在东西向图上硬套南北向现象。

东西向与南北向共享 Service 对象与 CT，但不共享入口岗位：NodePort 可能在 XDP 早路径应答，而 Pod→ClusterIP 可能在 cgroup connect 或 TC 路径完成 VIP 转换。若复盘时混用两种入口的抓包点，会得到「包消失」的假象——其实包在另一条挂载岗位上被改写或丢弃。第 6 篇会按流量类型画分叉；本篇要求先具备「同一 LB map、不同入口 hook」的心理模型。

相对 iptables/IPVS kube-proxy：经典路径上 ClusterIP DNAT 与 conntrack 状态住在 netfilter；KPR 主路径上等价状态住在 BPF LB/CT map。迁移期若集群仍开共存模式，同一 VIP 可能在不同节点落到不同实现——这是第 6 篇的互操作主题，本篇只警告：不要假设全集群东西向停顿点拓扑完全一致，先确认节点 datapath 模式。

相对 envoy/16 / haproxy/14：当排除树指向「L3/L4 + 身份即可」时，本篇描述的就是那片叶子内部的包路径；一旦停顿点落到 L7 Policy / Envoy，就应切回用户态代理坐标系，而不是继续在 CT 里找 HTTP 路由问题。

再补一条与策略编译的衔接：NetworkPolicy 未选中的流量在「默认拒绝」命名空间里会在 Endpoint Policy 岗位直接 drop，包可能永远到不了 Service 查找。因此「VIP 不通」仍要先排除源/目的策略，再查 LB map——顺序颠倒会把策略问题误判成 kube-proxy 替代缺陷。第 7 篇会回到编译产物如何生成这些 drop。

七、学术谱系、争论与开放问题

谱系：端到端「life of a packet」叙述来自系统论文与教学传统（从网卡到套接字逐层标定）。XDP 论文强调早路径；Cilium 文档用 Endpoint Policy / Service / Socket Enforcement 把微服务身份与 Service 抽象嵌进同一条可编程路径。相对经典 netfilter：匹配与状态从链与内核 CT迁到 hook + BPF map，更新从批量 iptables-restore 迁到 map 原子更新——收益与失败模式一并迁移。

这一迁移也改写了「中间盒」研究里的位置：传统中间盒在 L3 路由旁路或网关节点；Cilium 把策略与 LB 推到每个节点的 endpoint 邻接处。代价是排障必须分布式——不能假设存在单一 chokepoint 交换机镜像口能看见所有东西向决策。Hubble 正是对这一分布性的工程回应（第 8 篇），但它采样与真实停顿对齐仍是开放问题。

争论：IP 直连可观测性 vs Service 抽象

工程上两者都要会：用直连 IP 区分「策略/身份」与「Service/CT」；用 VIP 验证应用真实路径。禁止只拿一种连通性绿色证明另一种。

开放问题：

1. Hubble 采样与真实丢包点是否对齐——第 8、13 篇。
2. 标签风暴下跨节点身份收敛是否成为东西向主故障源——第 2、7、13 篇。
3. 何时东西向 L7 必须离开本路径进入 sidecar/Ambient——第 10、14–16 篇。
4. 同节点 socket 加速在开启主机防火墙 / 加密时的组合路径是否仍可一眼画清——需结合第 3、9 篇的挂载与加密岗位，避免「加速开启却路径变长」的直觉冲突。

八、小结

1. 东西向先点名停顿点：策略、Service LB、CT、socket 加速、overlay/加密、L7。
2. 同节点 socket 加速不取消握手阶段的策略穿越。
3. 经 ClusterIP 的路径多 LB/CT 停顿；跨节点再叠加转发与身份缓存。
4. 「旁路 netfilter」是主路径目标；回退与共存时机器上仍可能有 iptables。
5. 下一篇用同一词汇展开 kube-proxy 替代的南北向与 Service 细路径。

九、参考资料

规范 / 官方文档（A）

• Cilium v1.20 Life of a Packet — docs.cilium.io/en/v1.20/network/ebpf/lifeofapacket/。
• Cilium v1.20 eBPF Datapath Introduction — docs.cilium.io/en/v1.20/network/ebpf/intro/。
• Cilium v1.20 Iptables Usage — docs.cilium.io/en/v1.20/network/ebpf/iptables/。
• Cilium v1.20 eBPF Maps — docs.cilium.io/en/v1.20/network/ebpf/maps/。

源码（A）

• bpf/bpf_lxc.c、bpf/bpf_host.c、bpf/bpf_sock.c、bpf/lib/{policy,lb,nat,nodeport}.h @ v1.20.0

核心论文 / 对照

• Høiland-Jørgensen et al., The eXpress Data Path, CoNEXT 2018 —— 早路径假设。
• 站内 k8s-network/21 —— eBPF vs netfilter 争论入口。

站内对照

• 第 1–4 篇
• k8s-network/13
• Envoy 选型 · HAProxy 选型

实验台账

• 本篇无抓包输出；停顿表为机制推导 + 官方路径图。

→ 上一篇：关键 BPF Map · 系列目录 · 下一篇：kube-proxy 替代（规划）