全景剖析阿里云容器网络数据链路（七）：Terway DataPath V2（Terway≥1.8.0）

作者：余凯

前言

近几年，企业基础设施云原生化的趋势越来越强烈，从最开始的 IaaS 化到现在的微服务化，客户的颗粒度精细化和可观测性的需求更加强烈。容器网络为了满足客户更高性能和更高的密度，也一直在高速的发展和演进中，这必然对客户对云原生网络的可观测性带来了极高的门槛和挑战。为了提高云原生网络的可观测性，同时便于客户和前后线同学增加对业务链路的可读性，ACK 产研和 AES 联合共建，梳理云原生网络数据面可观测性系列，帮助客户和前后线同学了解云原生网络架构体系，简化对云原生网络的可观测性的门槛，优化客户运维和售后同学处理疑难问题的体验 ，提高云原生网络的链路的稳定性。

鸟瞰容器网络，整个容器网络可以分为三个部分：Pod 网段，Service 网段和 Node 网段。这三个网络要实现互联互通和访问控制，那么实现的技术原理是什么？整个链路又是什么，限制又是什么呢？Flannel，Terway 有啥区别？不同模式下网络性能如何？这些，需要客户在下搭建容器之前，就要依据自己的业务场景进行选择，而搭建完毕后，相关的架构又是无法转变，所以客户需要对每种架构特点要有充分了解。比如下图是个简图，Pod 网络既要实现同一个 ECS 的 Pod 间的网络互通和控制，又要实现不同 ECS Pod 间的访问，Pod 访问 SVC 的后端可能在同一个 ECS 也可能是其他 ECS，这些在不同模式下，数据链转发模式是不同的，从业务侧表现结果也是不一样的。

本文是[全景剖析容器网络数据链路]第七部分，主要介绍 Kubernetes Terway DataPath V2 模式下，数据面链路的转发链路，一是通过了解不同场景下的数据面转发链路，从而探知客户在不同的场景下访问链路的数据面表现，帮助客户进一步优化业务架构；另一方面，通过深入了解转发链路，从而在遇到容器网络抖动时候，客户运维以及阿里云同学可以知道在哪些链路点进行部署观测手动，从而进一步定界问题方向和原因。

系列一：全景剖析阿里云容器网络数据链路（一）—— Flannel

系列二：全景剖析阿里云容器网络数据链路（二）—— Terway ENI

系列三：全景剖析阿里云容器网络数据链路（三）—— Terway ENIIP

系列四：全景剖析阿里云容器网络数据链路（四）—— Terway IPVLAN+EBPF

系列五：全景剖析阿里云容器网络数据链路（五）—— Terway ENI-Trunking

系列六：全景剖析阿里云容器网络数据链路（六）—— ASM Istio 

Terway DataPath V2 模式架构设计

弹性网卡（ENI）支持配置多个辅助 IP 的功能，单个弹性网卡（ENI）根据实例规格可以分配 6～20 个辅助 IP，ENI 多 IP 模式就是利用了这个辅助 IP 分配给容器，从而大幅提高了 Pod 部署的规模和密度。在网络联通的方式上，Terway 目前支持 veth pair 策略路由和 IPVLAN 两种方案，但是社区在 cilium v1.12 版本后废弃了 IPVLAN 的支持 [ 1] ，为了统一数据面一致性，将 ACK 的数据面演进和社区保持一致，便于云原生的能力集成，减少差异化。从 v1.8.0 开始，Terway 不再支持 IPvlan 隧道加速，而采用 DataPath V2 的方式进行数据面的统一。

Pod 所使用的 CIDR 网段和节点的 CIDR 是同一个网段。

Pod 内部有一张网卡 eth0，其中 eth0 的 IP 就是 Pod 的 IP，此网卡的 MAC 地址和控制台上的 ENI 的 MAC 地址不一致，同时 ECS 上有多张 ethx 的网卡，说明 ENI 附属网卡并不是直接挂载到了 Pod 的网络命名空间。

Pod 内只有指向 eth0 的默认路由，说明 Pod 访问任何地址段都是从 eth0 为统一的出入口。

同时 ECS 上有多张 ethx 的网卡，说明 ENI 附属网卡并不是直接挂载到了 Pod 的网络命名空间。

通过 OS Linux Routing 可以得到，所有目的是 Pod IP 的流量都会被转发到 Pod 对应的 calixx 虚拟往卡上。因此，ECS OS 和 Pod 的网络命名空间已经建立好完整的出入链路配置了。

对于 ENI 多 IP 的实现，这个类似于 ACK 容器网络数据链路（Terway ENIIP） [ 2] 原理，Terway Pod 是通过 Daemonset 的方式部署在每个节点上的。通过 terway-cli mapping 命令可以得到节点上的附属 ENI 数量、MAC 地址以及每个 ENI 上的 IP。

对于 Pod 访问 SVC，容器是利用各种办法将请求转发到 Pod 所在的 ECS 层面，由 ECS 内的 netfilter 模块来实现 SVC IP 的解析。但是由于数据链路需要从 Pod 的网络命名空间切换到 ECS 的 OS 的网络命名空间，中间经过了对此内核协议栈，必然会产生性能损失，如果对高并发和高性能有机制追求，可能并不完全满足客户的需求。相比较 IPVLAN 模式将 eBPF 部署在 Pod 内部用于 SVC 地址转换，DataPath V2 模式的 eBPF 监听在每个 Pod 的 calixxx 网卡上，用于实现 Pod 和 Pod 访问的加速，以及 Pod 访问 SVC IP 的地址转后的链路加速，模式比较可以参考使用 Terway 网络插件 [ 3] 。

BPF Routing

5.10 内核以后，Cilium 新增了 eBPF Host-Routing 功能，新增了 bpf_redirect_peer 和 bpf_redirect_neigh 两个 redirect 方式。

• bpf_redirect_peer

• 数据包不经过宿主机的 lxc 接口，直接被送到 veth pair Pod 里面接口 eth0 上，实现数据包少进入一次 cpu backlog queue 队列，获得更好的转发性能。

• bpf_redirect_neigh

• 用来填充 pod egress 流量的 src 和 dst mac 地址，流量无需经过 kernel 的 route 协议栈处理过程。

故 Terway DataPath V2 模式总体可以归纳为：

• 目前低版本内核（低于 4.2）不支持 eBPF 加速，Aliyun2 可获得部分加速能力，Aliyun3 可获得完整的加速能力。

• 节点访问 Pod 需要经过 Host 的协议栈，Pod 和 Pod 间访问以及 Pod 访问 SVC 不经过 Host 的协议栈。

• DataPath V2 模式下，如果 Pod 访问 SVC IP，SVC IP 在 Pod 的 veth pair calixxx 网卡上被 eBPF 转为某个 SVC 后端 Pod 的 IP，之后数据链路绕过 Host 协议栈。也就是说 SVC IP 只会在源端 Pod 的 veth pair 被捕获，目的端 Pod 和目的端的 Pod 所在 ECS 都无法被捕获到。

Terway DataPath V2 模式容器网络数据链路剖析

针对容器网络特点，可以将 Terway datapathv2 模式下的网络链路大体分为以 Pod IP 对外提供服务和以 SVC 对外提供服务两个大的 SOP 场景，进一步细分，可以归纳为 11 个不同的小的 SOP 场景。

对这 15 个场景的数据链路梳理合并，这些场景可以总结为下面 8 类典型的场景：

• 访问 Pod IP，同节点访问 Pod

• 访问 Pod IP，同节点 Pod 间互访（Pod 属于同 ENI）

• 访问 Pod IP，同节点 Pod 间互访（Pod 属于不同 ENI）

• 访问 Pod IP，不同节点间 Pod 之间互访

• 集群内 Pod 访问的 SVC Cluster IP/External IP，SVC 后端 Pod 和客户端 Pod 属同 ECS 同 ENI

• 集群内 Pod 访问的 SVC Cluster IP/External IP，SVC 后端 Pod 和客户端 Pod 属同 ECS 不同 ENI

• 集群内 Pod 访问的 SVC Cluster IP/External IP，SVC 后端 Pod 和客户端 Pod 属于不同 ECS

• 集群外访问 SVC External IP

场景一：访问 Pod IP，同节点访问 Pod(含节点访问后端为同一节点的 SVC ClusterIP)

环境

xxx.10.0.1.219 节点上存在 nginx2-7ff4679659-xkpmm，IP 地址 10.0.0.2。

内核路由

nginx2-7ff4679659-xkpmm，IP 地址 10.0.0.2，该容器在宿主机中的 PID 是 5630，容器网络命名空间有指向容器 eth0 的默认路由。

该容器 eth0 在 ECS OS 内对应 veth pair 是 cali10e985649a0，在 ECS OS 内，有指向 Pod IP，下一跳为 calixxx 的路由，通过前文可以知道 calixxx 网卡是和每个 Pod 内的 veth1 组成的 pair。

通过下面的命令我们可以获取到 nginx2-7ff4679659-xkpmm，IP 地址 10.0.0.2 被 terway 分配到了 eth2 附属网卡。

kubectl --kubeconfig kubeconfig -n kube-system exec -it terway-eniip-v5v2p -c terway -- terway-cli mapping

小结

ECS 的 eth0 捕获了从 nginx2-7ff4679659-xkpmm 返回的数据，但是没有捕获发送数据。

ECS 的 eth1 同样也捕获了从 nginx2-7ff4679659-xkpmm 返回的数据，但是没有捕获发送数据。

cali10e985649a0 可以捕获发和收的数据包。

后续小结不再展示数据报文观测。

数据链路转发示意图（Aliyun2&Aliyun3）：

• 整个链路是经过了 ECS 和 Pod 的网络协议栈。

• 整个请求链路是：ECS OS -> calixxx -> ECS Pod eth0

场景二：访问 Pod IP，同节点 Pod 间互访（Pod 属于同 ENI）

环境

xxx.10.0.1.219 节点上存在 nginx2-7ff4679659-xkpmm，IP 地址 10.0.0.2 和 centos-5bf8644bcf-jqxpk，IP 地址 10.0.0.13。

内核路由

centos-5bf8644bcf-jqxpk，IP 地址 10.0.0.13，该容器在宿主机中的 PID 是 126938，容器网络命名空间有指向容器 eth0 的默认路由。

该容器 eth0 在 ECS OS 内对应 veth pair 是 calia7003b8c36c，在 ECS OS 内，有指向 Pod IP，下一跳为 calixxx 的路由，通过前文可以知道 calixxx 网卡是和每个 Pod 内的 veth1 组成的 pair。

nginx2-7ff4679659-xkpmm，IP 地址 10.0.0.2，该容器在宿主机中的 PID 是 5630，容器网络命名空间有指向容器 eth0 的默认路由。

该容器 eth0 在 ECS OS 内对应 veth pair 是 cali10e985649a0，在 ECS OS 内，有指向 Pod IP，下一跳为 calixxx 的路由，通过前文可以知道 calixxx 网卡是和每个 Pod 内的 veth1 组成的 pair。

通过下面的命令我们可以获取到 nginx2-7ff4679659-xkpmm 和 centos-5bf8644bcf-jqxpk 都被 terway 分配到了 eth2 同一张附属网卡。

kubectl --kubeconfig kubeconfig -n kube-system exec -it terway-eniip-v5v2p -c terway -- terway-cli mapping

小结

Aliyun2：

• 不会经过分配给 Pod 的附属网卡。

• 整个链路是经过了 Pod 的网络协议栈，链路由 Pod 的网络命名空间转发到对端时候，会经过 eBPF 加速绕过 OS 协议栈。

• 整个请求链路是：ECS Pod1 -> Pod1 calixxx -> Pod2 calixxx -> ECS Pod2。

Aliyun3：

• 不会经过分配给 Pod 的附属网卡。

• 整个链路会在 eBPF 的 ingress 被直接加速到目的 Pod 内，不会经过目的 Pod 的 calixxx 网卡。

• 整个请求链路是：

• 去方向：ECS Pod1 -> Pod1 calixxx -> ECS Pod2。

• 回方向：ECS Pod2 -> Pod2 calixxx -> ECS Pod1。

场景三：访问 Pod IP，同节点 Pod 间互访（Pod 属于不同 ENI）

环境

xxx.10.0.1.219 节点上存在 ngxin3-55f5c67988-p4qnb 和 centos-5bf8644bcf-jqxpk 两个 Pod，IP 地址分别为 10.0.0.251 和 10.0.0.13。

此节点的 terway Pod，利用 terway-cli mapping 的命令得到这两个 IP（10.0.0.251 和 10.0.0.13）都属于不同 ENI 网卡，在 OS 层面是被认为是 eth1 和 eth2。

内核路由

centos-5bf8644bcf-jqxpk，IP 地址 10.0.0.13，该容器在宿主机中的 PID 是 126938，容器网络命名空间有指向容器 eth0 的默认路由。

该容器 eth0 在 ECS OS 内对应 veth pair 是 calia7003b8c36c，在 ECS OS 内，有指向 Pod IP，下一跳为 calixxx 的路由，通过前文可以知道 calixxx 网卡是和每个 Pod 内的 veth1 组成的 pair。

ngxin3-55f5c67988-p4qnb，IP 地址 10.0.0.251，该容器在宿主机中的 PID 是 5630，容器网络命名空间有指向容器 eth0 的默认路由。

该容器 eth0 在 ECS OS 内对应 veth pair 是 cali08203025d22，在 ECS OS 内，有指向 Pod IP，下一跳为 calixxx 的路由，通过前文可以知道 calixxx 网卡是和每个 Pod 内的 veth1 组成的 pair。

小结

Aliyun2：

• 不会经过分配给 Pod 的附属网卡。

• 整个链路是经过了 Pod 的网络协议栈，链路由 Pod 的网络命名空间转发到对端时候，会经过 eBPF 加速绕过 OS 协议栈

• 整个请求链路是：ECS Pod1 -> Pod1 calixxx -> Pod2 calixxx -> ECS Pod2。

Aliyun3：

• 不会经过分配给 Pod 的附属网卡。

• 整个链路会在 eBPF 的 ingress 被直接加速到目的 Pod 内，不会经过目的 Pod 的 calixxx 网卡。

• 整个请求链路是：

• 去方向：ECS Pod1 -> Pod1 calixxx -> ECS Pod2。

• 回方向：ECS Pod2 -> Pod2 calixxx -> ECS Pod1。

场景四：访问 Pod IP，不同节点间 Pod 之间互访

环境

xxx.10.0.1.219 节点上存在 centos-5bf8644bcf-jqxpk，IP 地址为 10.0.0.13。

xxx.10.0.5.27 节点上存在 nginx1-7bcf4ffdb4-6rsqz，IP 地址为 10.0.4.121。

可以利用 terway-cli show factory 的命令得到 centos-5bf8644bcf-jqxpk 的 IP 10.0.0.13 属于 xxx.10.0.1.219 上的 MAC 地址为 00:16:3e:0d:74:23 的 ENI 网卡。

同理可得到 nginx1-7bcf4ffdb4-6rsqz 的 IP 10.0.4.121 属于 xxx.10.0.5.27 上的 MAC 地址为 00:16:3e:0c:ef:6c 的 ENI 网卡。

内核路由

centos-5bf8644bcf-jqxpk，IP 地址 10.0.0.13，该容器在宿主机中的 PID 是 126938，容器网络命名空间有指向容器 eth0 的默认路由。

该容器 eth0 在 ECS OS 内对应 veth pair 是 calia7003b8c36c，在 ECS OS 内，有指向 Pod IP，下一跳为 calixxx 的路由，通过前文可以知道 calixxx 网卡是和每个 Pod 内的 veth1 组成的 pair。

nginx1-7bcf4ffdb4-6rsqz，IP 地址 10.0.4.121，该容器在宿主机中的 PID 是 7745，容器网络命名空间有指向容器 eth0 的默认路由。

该容器 eth0 在 ECS OS 内对应 veth pair 是 cali06cd16bb25f，在 ECS OS 内，有指向 Pod IP，下一跳为 calixxx 的路由，通过前文可以知道 calixxx 网卡是和每个 Pod 内的 veth1 组成的 pair。

小结

Aliyun2：

• 会经过宿主机 OS 的网络命名空间，但协议栈链路会被 eBPF 加速。

• 整个链路是需要从客户端 Pod 所属的 ENI 网卡出 ECS 再从目的 Pod 所属的 ENI 网卡进入 ECS。

• 整个请求链路是 ECS1 Pod1 -> ECS1 Pod1 calixxx -> ECS1 ENI ethx -> VPC -> ECS2 ENI ethx -> ECS2 Pod2 calixxx -> ECS2 Pod2。

Aliyun3：

• 整个链路是需要从客户端 Pod 所属的 ENI 网卡出发，再经过 ECS 再从目的 Pod 所属的 ENI 网卡进入 ECS。

• 整个请求链路是：

• 去方向：ECS1 Pod1 -> ECS1 Pod1 calixxx -> ECS1 ENI ethx -> VPC -> ECS2 ENI ethx -> ECS2 Pod2。

• 回方向：ECS2 Pod2 -> ECS2 Pod2 calixxx -> ECS2 ENI ethx -> VPC -> ECS1 ENI ethx -> ECS1 Pod1。

场景五：集群内 Pod 访问的 SVC Cluster IP/External IP，SVC 后端 Pod 和客户端 Pod 属同 ECS 同 ENI

环境

xxx.10.0.1.219 节点上存在 nginx2-7ff4679659-xkpmm，IP 地址 10.0.0.2 和 centos-5bf8644bcf-jqxpk，IP 地址 10.0.0.13。

其中 nginx2-7ff4679659-xkpmm Pod 是 SVC nginx2 的 endpoint。

内核路由

内核路由类似场景 2，此处不再叙述。

关于 eBPF，在 datapathv2 中，eBPF 监听在 OS 层面的 calixxx 网卡上，而非 Pod 内部。利用 cilium 去调用 eBPF 的能力，可以通过图示命令可以得到 centos-5bf8644bcf-jqxpk 和 nginx2-7ff4679659-xkpmm identity ID 分别是 693 和 2702。

找到 Pod 所在的 ECS 的 Terway Pod 为 terway-eniip-v5v2p，在 Terway Pod 中运行 cilium bpf lb list | grep -A5 192.168.152.119 命令可以得到 eBPF 中对于 Cluster IP 192.168.152.119:80 记录的后端是 10.0.0.2:80。

小结

从客户端 Pod centos-5bf8644bcf-jqxpk 访问 SVC。

客户端的 centos-6c48766848-znkl8 的 calia7003b8c36c 网卡观测，可以捕获 SVC 的 IP 和客户端的 Pod IP。

在这个 Pod centos-6c48766848-znkl8 所属的附属网卡 ENI 上观测，未能捕获任何相关流量报文，说明流量从客户端的所属的 calixx 网卡到 ENI 之间经过了 eBPF 转换。

在 Pod nginx2-7ff4679659-xkpmmI 的 cali10e985649a0 观测，只能捕获 centos 和 nginx 的 Pod IP。

cilium 提供了一个 monitor 的功能，使用 cilium monitor --related-to < endpoint ID > ，可以得到：源端 Pod IP 访问 SVC IP 192.168.152.119，之后被解析到 SVC 的后端 Pod IP 10.0.0.2，说明 SVC IP 直接在 tc 层做了转发。

Aliyun2：

• 整个链路是经过了 Pod 的网络协议栈，链路由 Pod 的网络命名空间转发到对端时候，会经过 eBPF 加速绕过 OS 协议栈。

• 整个链路请求未经过 Pod 所分配的 ENI。

• SVC IP 在客户端 Pod 的 calixxx 网卡通过 eBPF 转换成了 SVC 后端 Pod 的 IP，后续节点无法捕获 SVC IP。

• 整个请求链路是：ECS Pod1 -> Pod1 calixxx -> Pod2 calixxx -> ECS Pod2。

Aliyun3：

• 整个链路是经过了 Pod 的网络协议栈，链路由 Pod 的网络命名空间转发到对端时候，会经过 eBPF 加速绕过 OS 协议栈。

• 整个链路请求未经过 Pod 所分配的 ENI。

• SVC IP 在客户端 Pod 的 calixxx 网卡通过 eBPF 转换成了 SVC 后端 Pod 的 IP，后续节点无法捕获 SVC IP。

• 整个链路会在 eBPF 的 ingress 被直接加速到目的 Pod 内，不会经过目的 Pod 的 calixxx 网卡。

• 整个请求链路是：

• 去方向：ECS Pod1 -> Pod1 calixxx -> ECS Pod2。

• 回方向：ECS Pod2 -> Pod2 calixxx -> ECS Pod1。

场景六：集群内 Pod 访问的 SVC Cluster IP/External IP，SVC 后端 Pod 和客户端 Pod 属同 ECS 不同 ENI

环境

xxx.10.0.1.219 节点上存在 ngxin3-55f5c67988-p4qnb，IP 地址 10.0.0.251 和 centos-5bf8644bcf-jqxpk，IP 地址 10.0.0.13。

其中 ngxin3-55f5c67988-p4qnb Pod 是 SVC nginx3 的 endpoint。

内核路由

内核路由类似场景 3，此处不再叙述。

关于 eBPF，在 datapathv2 中，eBPF 监听在 OS 层面的 calixxx 网卡上，而非 Pod 内部。利用 cilium 去调用 eBPF 的能力，可以通过图示命令可以得到 centos-5bf8644bcf-jqxpk 和 ngxin3-55f5c67988-p4qnb identity ID 分别是 693 和 94。

找到 Pod 所在的 ECS 的 Terway Pod 为 terway-eniip-v5v2p，在 Terway Pod 中运行 cilium bpf lb list | grep -A5 192.168.239.183 命令可以得到 eBPF 中对于 Cluster IP 192.168.239.183:80 记录的后端是 10.0.0.2:80。

小结

从客户端 Pod centos-5bf8644bcf-jqxpk 访问 SVC。

客户端的 centos-6c48766848-znkl8 的 calia7003b8c36c 网卡观测，可以捕获 SVC 的 IP 和客户端的 Pod IP。

在 Pod centos-6c48766848-znkl8 所属的附属网卡 ENI 和 ngxin3-55f5c67988-p4qnb 所属的附属网卡 ENI 上观测，未能捕获到相关流量，说明流量从客户端的所属的 calixx 网卡上被 eBPF 转换成 SVC 相关的 endpoint 后直接被短路到目的 calixxx 网卡。

在 Pod ngxin3-55f5c67988-p4qnb 所属的 cali08203025d22 观测，只能捕获 centos 和 nginx 的 Pod IP。

cilium 提供了一个 monitor 的功能，使用 cilium monitor --related-to < endpoint ID >，可以得到：源端 Pod IP 访问 SVC IP 192.168.239.183，之后被解析到 SVC 的后端 Pod IP 110.0.0.251，说明 SVC IP 直接在 tc 层做了转发。

后续小节如果涉及 SVC IP 的访问，如有类似，不再做详细的说明。

Aliyun2：

• 会经过宿主机 OS 的网络命名空间，但协议栈链路会被 eBPF 加速。

• 整个链路请求未经过 Pod 所分配的 ENI。

• SVC IP 在客户端 Pod 的 calixxx 网卡通过 eBPF 转换成了 SVC 后端 Pod 的 IP，后续节点无法捕获 SVC IP。

• 整个请求链路是 ECS1 Pod1 -> ECS1 Pod1 calixxx -> ECS2 Pod2 calixxx -> ECS2 Pod2。

Aliyun3：

• 不会经过分配给 Pod 的附属网卡。

• 整个链路会在 eBPF 的 ingress 被直接加速到目的 Pod 内，不会经过目的 Pod 的 calixxx 网卡。

• SVC IP 在客户端 Pod 的 calixxx 网卡通过 eBPF 转换成了 SVC 后端 Pod 的 IP，后续节点无法捕获 SVC IP。

• 整个请求链路是：

• 去方向：ECS Pod1 -> Pod1 calixxx -> ECS Pod2。

• 回方向：ECS Pod2 -> Pod2 calixxx -> ECS Pod1。

场景七：集群内 Pod 访问的 SVC Cluster IP/External IP，SVC 后端 Pod 和客户端 Pod 属于不同 ECS

环境

xxx.10.0.1.219 节点上存在 centos-5bf8644bcf-jqxpk，IP 地址为 10.0.0.13。

xxx.10.0.5.27 节点上存在 nginx1-7bcf4ffdb4-6rsqz，IP 地址为 10.0.4.121。

其中 nginx1-7bcf4ffdb4-6rsqz Pod 是 SVC nginx1 的 endpoint。

内核路由

Pod 访问 SVC 的 Cluster IP，而 SVC 的后端 Pod 和客户端 Pod 部署在不同 ECS 上，此架构和场景四：不同节点间 Pod 之间互访 [ 4] 小节相似，只不过此场景是 Pod 访问 SVC 的 Cluster IP。对于 Cluster IP 的 eBPF 转发进行描述，详情请见场景五和场景六。

小结

Aliyun2：

• 会经过宿主机 OS 的网络命名空间，但协议栈链路会被 eBPF 加速。

• 整个链路是需要从客户端 Pod 所属的 ENI 网卡出 ECS 再从目的 Pod 所属的 ENI 网卡进入 ECS。

• 整个请求链路是 ECS1 Pod1 -> ECS1 Pod1 calixxx -> ECS1 ENI ethx -> VPC -> ECS2 ENI ethx -> ECS2 Pod2 calixxx -> ECS2 Pod2。

Aliyun3：

• 整个链路是需要从客户端 Pod 所属的 ENI 网卡出发，再经过 ECS 再从目的 Pod 所属的 ENI 网卡进入 ECS。

• 整个请求链路是：

• 去方向：ECS1 Pod1 -> ECS1 Pod1 calixxx -> ECS1 ENI ethx -> VPC -> ECS2 ENI ethx -> ECS2 Pod2。

• 回方向：ECS2 Pod2 -> ECS2 Pod2 calixxx -> ECS2 ENI ethx -> VPC -> ECS1 ENI ethx -> ECS1 Pod1。

场景八：集群外访问 SVC External IP

环境

xxx.10.0.5.27 节点上存在 nginx1-7bcf4ffdb4-6rsqz，IP 地址为 10.0.4.121。

通过 describe SVC 可以得到 nginx Pod 被加入到了 SVC nginx 的后端。SVC 的 Cluster IP 是 192.168.190.78。

内核路由

在 SLB 控制台，可以得到 lb-3nsj50u4gyz623nitxxx 虚拟服务器组的后端服务器组是两个后端 nginx Pod 的 ENI eni-j6cgs979ky3evxxx。

从集群外部角度看，SLB 的后端虚拟服务器组是 SVC 的后端 Pod 所属的 ENI 网卡，内网的 IP 地址就是 Pod 的地址。

小结

Aliyun2：

• ExternalTrafficPolicy 为 Local 或 Cluster 模式下，SLB 只会将 Pod 分配的 ENI 挂载到 SLB 的虚拟服务器组。

• 数据链路会经过 Pod 的 Veth 的 calixxx 网卡

• 数据链路：Client -> SLB -> Pod ENI + Pod Port -> ECS1 Pod1 calixxx -> ECS1 Pod1 eth0。

Aliyun3：

• ExternalTrafficPolicy 为 Local 或 Cluster 模式下，SLB 只会将 Pod 分配的 ENI 挂载到 SLB 的虚拟服务器组。

• 数据链路会被 ECS 的附属网卡上 eBPF 加速绕过 Pod 的 Veth 的 calixxx 网卡，直接进到 Pod 的网络命名空间。

• 数据链路：Client -> SLB -> Pod ENI + Pod Port -> ECS1 Pod1 eth0。

相关链接：

[1] 废弃了 IPVLAN 的支持

https://docs.cilium.io/en/v1.12/operations/upgrade/#deprecated-options

[2] ACK 容器网络数据链路（Terway ENIIP）

https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/user-guide/ack-network-fabric-terway-eniip

[3] 使用 Terway 网络插件

https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/user-guide/work-with-terway

[4] 不同节点间 Pod 之间互访https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/user-guide/ack-network-fabric-terway-eni-trunking#RS9Nc