大家好，我是二哥。本篇 3700 字，阅读大概需要 20 分钟，下面是内容概览。
本文是书稿《图解 VPC & K8s 网络模型》其中一篇。书稿还在继续写，进度不快也不慢，因为二哥不急也不躁。好肉需要慢炖，好书需要多磨。
为什么要单独讲这个话题呢？因为我在和同事讨论 K8s 网络尤其是网络数据流向的时候，会反复提及到网络设备，无论它是物理的还是虚拟的。而网络设备在我们所讨论到的数据流场景里，时而在接收数据，时而在发送数据。也就是说它同时扮演着双重身份：Ingress 和 Egress。
另外我在整理 eBPF 相关的内容，尤其是 tc eBPF 的时候，再一次发现如果不能准确地在数据流中识别出网络设备是 Ingress 还是 Egress ，就无法将代码逻辑和实际运行结果对上号，更勿谈能理解tc eBPF 了。
这样的双重角色扮演就如同一个调皮的孩子，总是带上面具在错综复杂的网络里面东躲西藏，肆意玩耍。而当你好不容易抓到它时，却让你猜猜此时此刻他是谁。
简单来说：对于网卡而言，无论它是物理的还是虚拟的，对于 Ingress 角色，它是首先触碰到数据的人，而对于 Egress 角色，它是最后一个碰到数据的人。
本文我们从一个简单的物理网卡开始，然后对 veth、 bridge 还有 tc eBPF ，分别展开聊聊：
图 1
这是一个简单的图，图中有一张物理网卡。我们的台式机通常是这样的配置。橘色的线代表着输入流程，而蓝色的线表示输出流程。
对于这张网卡而言，输入过程伴随着以下几个重要的事情：物理网卡首先接收到物理信号 -> 物理网卡通过 DMA 机制将数据保存至其专属的 RingBuffer 里面 -> 向 CPU 发起中断 -> OS kernel thread ksoftirqd/x 不断地消费 RingBuffer 里面的数据。
这里的 ksoftirqd 是一个内核线程，每个 CPU 一个，x 为 CPU 编号。如 ksoftirqd/0 为 0 号 CPU 上运行的内核线程。
ksoftirqd/x 将数据以 skb 为处理粒度依次穿过链路层、网络层、TCP/UDP 传输层 。不过 skb 在链路层和网络层还可能直接 forward 给其它网卡，那这样的话传输层就不会收到这个 skb 了。
整个过程如图 2 所示，你可以从整体上感受一下。标号 1 及 1.x 为数据输入和生产过程，这是本文的重点。而标号 3 为数据消费过程，它带着 skb 从入口处的 net_rx_action() 沿着协议栈由底向上穿越协议栈，这个过程对本文所述的所有 Ingress 场景都是通用的，故后文不再赘述这部分。
图 2
总结：当物理网卡扮演 Ingress 角色时，它从主机外接收数据，将数据递交给了环形队列，然后由 ksoftirqd/x 进行后续的处理，这个处理过程也称为网络栈下半部分。
从图 1 中，我们大致可以看出来，对于输出过程，数据来源有两种，分别是通过 ip_forward() 过程和通过 ip_local_out() 过程送过来的数据。我们还会发现，在发送数据的路径上，这两个过程只是起点有些不同，剩下的路程大家都一样。
ip_forward() 过程与 skb 在 IP 层路由结果强相关。如图 3 所示，具体来说经过路由的判定，可能需要把 skb forward 至本机网络设备或者网络中的其它主机处理，不过无论是哪种情况，都需要将 skb 送往本机的一个网络设备。
图 3
而 ip_local_out() 过程则对应了本机进程通过 socket 发送数据的场景，如图 4 所示。这张图最后标注的“触发 NET_RX 类型软中断”是数据已经被网卡发送完后发生的事情，中断的目的是为了清理 skb ，略过不表。
图 4 ，图片来源：“开发内功修炼”公众号
总结：当物理网卡扮演 Egress 角色时，它从本机 TCP/IP 协议栈接收数据，将数据通过驱动程序送离本机。
是不是觉得单个网卡的场景其实很容易分辨出来 Ingress 和 Egress ?
别得意，我们来加点难度。我们知道 K8s 的默认 CNI flannel 用到了 veth 。veth 是什么以及它的特性二哥就不细说了。我们聊一个话题：图 5 中，当左侧进程向右侧进程通信发送数据时， 左端的 veth_left 是 Ingress 还是 Egress ? 右端的 veth_right 呢？
图 5
结合图 5 上的箭头示意，答案应该不难猜。对 veth_left 来说，它扮演的是 Egress 角色，因为进程需要通过它把数据发送出去。对 veth_right 而言是 Ingress ，因为它需要负责接收数据并把它送给右侧的进程。
下一个问题：既然 veth_left 扮演了 Egress 角色，流量从离开 network namespace 1 之后去哪里了？既然 veth_right 是 Ingress ，那它从哪里接收到流量的？
答案都在图 6 里面。图中标号 2 及 2.x 在进行数据发送的工作，都属于 veth_left 的 Egress 的过程，这个过程是发生在 network namespace 1 里面的，函数调用栈和图 4 一样。而标号 3 为数据消费也即 veth_right 的 Ingress 过程，这个过程和物理网卡一模一样。
更多详细讲解请参考《看图写话：聊聊veth数据流》。
图 6
总结：既然 veth 是一对虚拟网卡，那我们把对它俩的总结放在一起。
当 veth 网卡扮演 Egress 角色时，如图 7 中的 veth_left，它从其所在的 network namespace TCP/IP 协议栈接收数据，并将数据递交给了 per CPU input_pkt_queue 队列，并触发软件中断。
当 veth 网卡扮演 Ingress 角色时，如图 7 中的 veth_right，它并没有物理网卡那种环形队列，而是由 ksoftirqd/x 直接从 per CPU input_pkt_queue 队列读取 veth_left 塞进来的数据。
veth_left 和 veth_right 共享了同一个 queue 。典型的生产者 / 消费者设计模式的即视感有没有？
图 7
上一节，二哥把 veth pair 单独拿出来和大家一起观赏。可它们终究不是花瓶，它们被创造出来是要有实际使用价值的。veth 典型使用场景就是把一端插入到 bridge 里面，如图 8 所示。
从 veth 的特性来说，流量从下图 veth1-left 流出后，会进入 veth1-right ，这也就意味着流量进入了网桥。
我想这个时候你可以确定 veth1-left 是 Egress ，而 veth1-right 是 Ingress 。那么对于 bridge 的 Port 1 和 Port 2 呢？再进一步，对于 veth2-left 和 veth2-right 呢 ?
图 8
其实对于 bridge 这种虚拟的网桥，它的 port 口也是一个虚拟的概念，说得更直白一点，在内核里它就是一个数据结构：struct net_bridge_port 。这个结构里有 3 个重要的成员：br / port_no / dev 。下面的代码用于插入网络设备到 bridge ，这 3 个成员的作用显而易见。
微博登录
QQ登录//file: net/bridge/br_if.c
static struct net_bridge_port *new_nbp(struct net_bridge *br,
struct net_device *dev)
{
//申请插口对象
struct net_bridge_port *p;
p = kzalloc(sizeof(*p), GFP_KERNEL);
//初始化插口
index = find_portno(br);
p->br = br;
p->dev = dev;
p->port_no = index;
...
}对于图 8 来说， Port 1 (net_bridge_port) 就是一个粘合剂，左手 bridge ，右手 veth1-right 。理解了这点也就明白了对于 bridge 的 Port 而言，它是没有所谓的 Ingress 和 Egress 的概念的。
Port 1 接收数据其实是 veth1-right 在 Ingress，而 bridge 把这个流量 forward 给 veth2-right 时，veth2-right 其实在扮演 Egress 角色。那流量从 veth2-right 传至 veth2-left 的过程和 veth1-left 向 veth1-right 发送数据的过程是完全一样的。
总结：当 veth 这样的虚拟网卡插入在 bridge 上时：
图8 中 veth1-left 扮演 Egress 角色，它从其所在的 network namespace TCP/IP 协议栈接收数据，将数据递交给了 per CPU input_pkt_queue 队列，并触发软件中断。
veth1-right 扮演 Ingress 角色，它并没有物理网卡那种环形队列，而是由 ksoftirqd/x 直接从 per CPU input_pkt_queue 队列读取 veth1-left 塞进来的数据。当 ksoftirqd/x 把流量送至链路层时，从 br_forward() 开始进入 forward 流程。这个流程的效果就是流量从 veth1-right 转至 veth2-right 发送出去了。
那自然 veth2-right 这个时候就扮演了 Egress 角色，veth2-left 扮演了 Ingress 角色。
如果你没有晕的话，那抖索一下精神，我们开始 veth-pair 的进阶版。
上一节我们看到 veth 和 bridge 搭配使用的场景。veth 另一端一定要插在 bridge 上吗？从图 9 你也看到了，答案是：不一定。
图 9
现在我们知道，在图 9 中，从 container-1 发出的流量经过 veth 发出后，veth-p 会以 Ingress 角色开始接收。根据前文的解释，当网卡进行 Ingress 时，流量会被 ksoftirqd/x 送往协议栈进一步处理。这个处理的过程当然也就包括了图 9 中的路由过程。
图 9 这里巧妙的地方是：流量是产生于容器内，但对这份流量的路由却发生在主机 root(default) network namespance 里面，使用的也是主机的路由表。如果路由结果发现需要把这份流量发往其它主机，那自然流量就从主机的 eth0 这个网卡设备离开了。在这个过程中，主机其实扮演了网关的角色。
说到这里，你能理解图 10 的工作过程了吗？它是 K8s host-gateway 网络模型，顾名思义，这种网络模型以 host 为 gateway ，更具体地说，host 的 root network namespace 充当了路由的角色。
图 10
如果你对 tc 和 eBPF 了解得不多或者不感兴趣，可以跳过这部分。
以 Cilium 为代表的 K8s CNI 提供商一直在尝试使用 eBPF 代替 iptables 以便优化服务网格数据面性能。其中 bpf_redicrect() 函数即为其中一项优化产出。
bpf_redicrect() 函数的特性用一句话就能解释清楚：当 veth Ingress 时，将流量直接通过 bpf_redirect() 重定向到另一个 veth Ingress。如图 11 所示。
不过如果你对 veth pair 哪一端在何时会扮演 Ingress 角色了解得不是很清楚的话，上面这句话其实会把你绕晕。
图 11
但在看完二哥这篇文章后，希望你不会再晕了。在图 11 中，从右下 Pod 出来的流量会流到位于 host network ns 这一端的 veth 上，这个 veth 是以 Ingress 角色工作的。
你看到在它身上附上了一个 eBPF 小蜜蜂图标，表示这个时候 eBPF 程序会介入执行，执行的结果就是流量被直接通过 dev_forward_skb() forward 给了另外一个同样位于 host network ns 端的 veth （如图 11 箭头所指的那个 veth），当然对这个 veth 而言，它会扮演 Egress 角色。
这个过程也可以用下面这样的函数调用层次图来表示。
pkt -> NIC -> TC ingress -> handle_ing()
|-verdict = tc_classify() // exec BPF code
| |-bpf_redirect() // return verdict
|
|-switch (verdict) {
case TC_ACK_REDIRECT:
skb_do_redirect() // to the target net device
|-if ingress:
| dev_forward_skb()
|-else:
dev_queue_xmit()下面是网易轻舟的一篇文章里面所附的图。它画出了网易轻舟基于 Cilium 网络方案的探索和实践细节，包括跨节点 Pod 间通信、同节点 Pod 间通信、Pod 访问外网等各类常见的场景。
图中 cilium_net/cilium_host 是一对 veth pair ，它们在 Kernel 4.19 + Cilium 1.8 部署中已经没什么作用了（事实上社区在考虑去掉它们）。
我想有了上面所有的铺垫和知识，至少对标号 ① ② 所示的流程，你应该能看得懂了。
图 12
文末，二哥来做个小总结：
