全景剖析阿里云容器网络数据链路（四）：Terway IPVLAN+EBPF
本系列文章由余凯执笔创作，联合作者：阿里云容器服务 谢石 对本文亦有贡献
近几年，企业基础设施云原生化的趋势越来越强烈，从最开始的 IaaS 化到现在的微服务化，客户的颗粒度精细化和可观测性的需求更加强烈。容器网络为了满足客户更高性能和更高的密度，也一直在高速的发展和演进中，这必然对云原生网络的可观测性带来了极高的门槛和挑战。为了提高云原生网络的可观测性，同时便于客户和前后线同学增加对业务链路的可读性，ACK 产研和 AES 联合共建，合作开发 ack net-exporter 和云原生网络数据面可观测性系列，帮助客户和前后线同学了解云原生网络架构体系，简化对云原生网络的可观测性的门槛，优化客户运维和售后同学处理疑难问题的体验 ，提高云原生网络的链路的稳定性。
鸟瞰容器网络，整个容器网络可以分为三个部分：Pod 网段，Service 网段和 Node 网段。这三个网络要实现互联互通和访问控制，那么实现的技术原理是什么？整个链路又是什么，限制又是什么呢？Flannel， Terway 有啥区别？不同模式下网络性能如何？这些，需要客户在下搭建容器之前，就要依据自己的业务场景进行选择，而搭建完毕后，相关的架构又是无法转变，所以客户需要对每种架构特点要有充分了解。比如下图是个简图，Pod 网络既要实现同一个 ECS 的 Pod 间的网络互通和控制，又要实现不同 ECS Pod 间的访问， Pod 访问 SVC 的后端可能在同一个 ECS 也可能是其他 ECS，这些在不同模式下，数据链转发模式是不同的，从业务侧表现结果也是不一样的。
本文是[全景剖析容器网络数据链路]第四部分部分，主要介绍 Kubernetes Terway EBPF+IPVLAN 模式下，数据面链路的转转发链路，一是通过了解不同场景下的数据面转发链路，从而探知客户在不同的场景下访问结果表现的原因，帮助客户进一步优化业务架构；另一方面，通过深入了解转发链路，从而在遇到容器网络抖动时候，客户运维以及阿里云同学可以知道在哪些链路点进行部署观测手动，从而进一步定界问题方向和原因。
系列五：全景剖析阿里云容器网络数据链路（五）—— Terway ENI-Trunking
系列六：全景剖析阿里云容器网络数据链路（六）—— ASM Istio
Terway IPVLAN+EBPF 模式架构设计
弹性网卡(ENI)支持配置多个辅助 IP 的功能，单个弹性网卡(ENI)根据实例规格可以分配 6-20 个辅助 IP，ENI 多 IP 模式就是利用了这个辅助 IP 分配给容器，从而大幅提高了 Pod 部署的规模和密度。在网络联通的方式上，Terway 支持选择 Veth pair 策略路由和 ipvlan l 两种方案，Linux 在 4.2 以上的内核中支持了 ipvlan 的虚拟网络，可以实现单个网卡虚拟出来多个子网卡用不同的 IP 地址，而 Terway 便利用了这种虚拟网络类型，将弹性网卡的辅助 IP 绑定到 IPVlan 的子网卡上来打通网络，使用这种模式使 ENI 多 IP 的网络结构足够简单，性能也相对 veth 策略路由较好。
ipvlan：
https://www.kernel.org/doc/Documentation/networking/ipvlan.txt
Pod 所使用的的 CIDR 网段和节点的 CIDR 是同一个网段
Pod 内部可以看到是有一张网卡的，一个是 eth0，其中 eth0 的 IP 就是 Pod 的 IP，此网卡的 MAC 地址和控制台上的 ENI 的 MAC 地址不一致，同时 ECS 上有多张 ethx 的网卡，说明 ENI 附属网卡并不是直接挂在到了 Pod 的网络命名空间
Pod 内有只有指向 eth0 的默认路由，说明 Pod 访问任何地址段都是从 eth0 为统一的出入口
那么 Pod 是如何 ECS OS 进行通信呢？在 OS 层面，我们一看到 ipvl_x 的网卡，可以看到是附属于 eth1 的，说明在 OS 层面会给每个附属网卡创建一个 ipvl_x 的网卡，用于建立 OS 和 Pod 内的连接隧道。
ECS OS 内对于数据流量是怎么判断去哪个容器呢？通过 OS Linux Routing 我们可以看到，所有目的是 Pod IP 的流量都会被转发到 Pod 对应的 ipvl_x 虚拟往卡上，到这里为止，ECS OS 和 Pod 的网络命名空间已经建立好完整的出入链路配置了。到目前为止介绍了 IPVLAN 在网络架构上的实现。
对于 eni 多 IP 的实现，这个类似于《全景剖析阿里云容器网络数据链路（三）—— Terway ENIIP》原理，Terway Pod 是通过 daemonset 的方式部署在每个节点上的，通过下面命令可以看到每个节点上的 Terway Pod。通过 terway-cli show factory 命令可以看到节点上的附属 ENI 数量、MAC 地址以及每个 ENI 上的 IP
那么对于 SVC 来说，是如何实现的呢？看过前面 四个系列的朋友，应该知道对于 Pod 访问 SVC，容器是利用各种办法将请求转发到 Pod 所在的 ECS 层面，由 ECS 内的 netfilter 模块来实现 SVC IP 的解析，这固然是个好办法，但是由于数据链路需要从 Pod 的网络命名空间切换到 ECS 的 OS 的网络命名空间，中间经过了 2 次内核协议栈，必然会产生性能损失，如果对高并发和高性能有极致追求，可能并不完全满足客户的需求。那么对于高并发和延迟敏感业务，该如何实现呢？有没有办法让 Pod 访问 SVC 直接在 Pod 的网络命名空间中就实现了后端解析，这样结合 IPVLAN 这样至实现了一次内核协议栈。在 4.19 版本内核中，ebpf 的出现，很好的实现了这个需求，这里不对 ebpf 做过多说明，感兴趣的可以访问官方链接，小伙伴们只需要知道 ebpf 是一种可以安全在内核层面运行的安全沙盒，当触发内核的指定行为，ebpf 设定程序会被执行。利用这个特性，我们可以实现在 tc 层面对访问 SVC IP 的数据包进行修改。
官方链接：
例如，同上图，可以看到集群内有一个名为 nginx 的 svc，clusterIP 是 192.168.27.242，后端 pod IP 是 10.0.3.38. 通过 cilium bpf lb list 可以看到在 ebpf 程序中对于 clusterIP 192.168.27.242 的访问会被转到 10.0.3.38 这个 IP 上， 而 Pod 内只有一个默认路由。此处说明，IPVLAN+EBPF 模式下，如果 Pod 访问 SVC IP，SVCIP 在 Pod 的网络命名空间内就会被 ebpf 转为某个 SVC 后端 pod 的 IP，之后数据链路被发出 Pod。也就是说 SVCIP 只会在 Pod 内被捕获，在源端 ECS，目的端 Pod 和目的端的 Pod 所在 ECS 都无法被捕获到。那假如一个 SVC 后后段有 100+ pod， 因为 ebpf 存在，Pod 外无法捕获到 SVCIP，所在一旦出现网络抖动，对于抓包该抓那个后端 IP 或该在哪个后端 Pod 出抓包呢？想一想，是不是一个非常头疼又无解的场景? 目前容器服务和 AES 共创了 ACK Net-Exporter 容器网络可观测性工具，可以针对此场景进行持续化的观测和问题判断。
ACK Net-Exporter 容器网络：
故 Terway IPVLAN+EBPF 模式总体可以归纳为：
4.2 以上内核中支持了 ipvlan 的虚拟网络，可以实现单个网卡虚拟出来多个子网卡用不同的 IP 地址，而 Terway 便利用了这种虚拟网络类型，将弹性网卡的辅助 IP 绑定到 IPVlan 的子网卡上来打通网络，使用这种模式使 ENI 多 IP 的网络结构足够简单，性能也相对 veth 策略路由较好。
节点访问 pod 需要经过 host 的协议栈，pod 和 pod 间访问 不经过 host 的 协议栈
IPVLAN+EBPF 模式下，如果 Pod 访问 SVC IP，SVCIP 在 Pod 的网络命名空间内就会被 ebpf 转为某个 SVC 后端 pod 的 IP，之后数据链路被发出 Pod。也就是说 SVCIP 只会在 Pod 内被捕获，在源端 ECS，目的端 Pod 和目的端的 Pod 所在 ECS 都无法被捕获到。
Terway IPVLAN+EBPF 模式容器网络数据链路剖析
针对容器网络特点，我们可以将 Terway IPVLAN+EBPF 模式下的网络链路大体分为以 Pod IP 对外提供服务和以 SVC 对外提供服务两个大的 SOP 场景，进一步细分，可以归纳为 12 个不同的小的 SOP 场景。
对这 11 个场景的数据链路梳理合并，这些场景可以归纳为下面 12 类典型的场景：
TerwayENI 架构下，不同的数据链路访问情况下，可以总结归纳为为 12 类：
访问 Pod IP， 同节点访问 Pod
访问 Pod IP，同节点 pod 间互访（pod 属于同 ENI）
访问 Pod IP，同节点 pod 间互访（pod 属于不同 ENI）
不同节点间 Pod 之间互访
集群内 Pod 访问的 SVC ClusterIP（含 Terway 版本≥1.2.0，访问 ExternalIP），SVC 后端 Pod 和客户端 Pod 配属同一个 ENI
集群内 Pod 访问的 SVC ClusterIP（含 Terway 版本≥1.2.0，访问 ExternalIP），SVC 后端 Pod 和客户端 Pod 配属不同 ENI（同 ECS）
集群内 Pod 访问的 SVC ClusterIP（含 Terway 版本≥1.2.0，访问 ExternalIP），SVC 后端 Pod 和客户端 Pod 不属于不同 ECS
集群内 Pod 访问的 SVC ExternalIP（Terway 版本≤1.2.0），SVC 后端 Pod 和客户端 Pod 配属同一个 ENI
集群内 Pod 访问的 SVC ExternalIP（Terway 版本≤1.2.0），SVC 后端 Pod 和客户端 Pod 配属不同 ENI（同 ECS）
集群内 Pod 访问的 SVC ExternalIP（Terway 版本≤1.2.0），SVC 后端 Pod 和客户端 Pod 部署于不同 ECS
集群外访问 SVC ExternalIP
2.1 场景一：访问 Pod IP，同节点访问 pod
环境
cn-hongkong.10.0.3.15 节点上存在 nginx-7d6877d777-j7dqz 和 10.0.3.38
内核路由
nginx-7d6877d777-j7dqz IP 地址 10.0.3.38 ，该容器在宿主机表现的 PID 是 329470，该容器网络命名空间有指向容器 eth0 的默认路由
该容器 eth0 在 ECS OS 内是通过 ipvlan 隧道的方式和 ECS 的附属 ENI eth1 建立的隧道，同时附属 ENI eth1 还有个虚拟的 ipvl_8@eth1 网卡
通过 OS Linux Routing 我们可以看到，所有目的是 Pod IP 的流量都会被转发到 Pod 对应的 ipvl_x 虚拟往卡上，这样就建立完毕 ECS 和 Pod 之间的连接隧道了。
小结：可以访问到目的端
nginx-7d6877d777-zp5jg netns eth0 可以抓到数据包
ECS 的 ipvl_8 可以抓到数据包
数据链路转发示意图
不会经过分配给 pod 的附属网卡
整个链路是通过查找路由表进入 ipvl_xxx，不需要经过 ENI
整个请求链路是 node -> ipvl_xxx -> ECS1 Pod1
2.2 场景二：访问 Pod IP，同节点 pod 间互访（pod 属于同 ENI）
环境
cn-hongkong.10.0.3.15 节点上存在 nginx-7d6877d777-j7dqz 和 centos-6c48766848-znkl8 两个 pod， IP 分别为 10.0.3.38 和 10.0.3.5
通过 此节点的 terway pod， 我们可以 利用 terway-cli show factory 的命令看到 这两个 IP （10.0.3.5 和 10.0.3.38）都属于同一个 MAC 地址 00:16:3e:04:08:3a ，说明这两个 IP 属于同一个 ENI，进而可以推断出 nginx-7d6877d777-j7dqz 和 centos-6c48766848-znkl8 属于同一个 ENI 网卡
内核路由
centos-6c48766848-znkl8 IP 地址 10.0.3.5，该容器在宿主机表现的 PID 是 2747933，该容器网络命名空间有指向容器 eth0 的默认路由, 有且只有一条，说明 pod 访问所有地址都需要通过该默认路由
nginx-7d6877d777-j7dqz IP 地址 10.0.3.38 ，该容器在宿主机表现的 PID 是 329470，该容器网络命名空间有指向容器 eth0 的默认路由
该容器 eth0 在 ECS OS 内是通过 ipvlan 隧道的方式和 ECS 的附属 ENI eth1 建立的隧道，同时附属 ENI eth1 还有个虚拟的 ipvl_8@eth1 网卡
小结：可以访问到目的端
centos-6c48766848-znkl8 netns eth0 可以抓到数据包
nginx-7d6877d777-zp5jg netns eth0 可以抓到数据包
ipvl_8 网卡 并没有捕获到相关的数据流量包
数据链路转发示意图
不会经过分配给 pod 的附属网卡
不会经过任何宿主机 ECS 的网络空间的中间节点
整个链路请求不会经过 pod 所分配的 ENI，直接在 OS 的 ns 中命中 Ip rule 被转发到对端 pod
整个请求链路是 ECS1 Pod1 -> ECS1 pod2 （发生在 ECS 内部）， 和 IPVS 相比，避免了 calico 网卡设备的两次转发，性能是更好的。
2.3 场景三：访问 Pod IP，同节点 pod 间互访（pod 属于不同 ENI）
环境
cn-hongkong.10.0.3.15 节点上存在 nginx-7d6877d777-j7dqz 和 busybox-d55494495-8t677 两个 pod， IP 分别为 10.0.3.38 和 10.0.3.22
通过 此节点的 terway pod， 我们可以 利用 terway-cli show factory 的命令看到 这两个 IP （10.0.3.22 和 10.0.3.38）都属于同一个 MAC 地址 00:16:3e:01:b7:bd 和 00:16:3e:04:08:3a ，说明这两个 IP 属于不同 ENI，进而可以推断出 nginx-7d6877d777-j7dqz 和 busybox-d55494495-8t677 属于不同 ENI 网卡
内核路由
busybox-d55494495-8t677 IP 地址 10.0.3.22 ，该容器在宿主机表现的 PID 是 2956974，该容器网络命名空间有指向容器 eth0 的默认路由, 有且只有一条，说明 pod 访问所有地址都需要通过该默认路由
nginx-7d6877d777-j7dqz IP 地址 10.0.3.38 ，该容器在宿主机表现的 PID 是 329470，该容器网络命名空间有指向容器 eth0 的默认路由
该容器 eth0 在 ECS OS 内是通过 ipvlan 隧道的方式和 ECS 的附属 ENI eth1 建立的隧道，通过 mac 地址一样可以看到，nginx-7d6877d777-j7dqz 和 busybox-d55494495-8t677 分别被分配 eth1 和 eth2
小结：可以访问到目的端
busybox-d55494495-8t677 netns eth0 可以抓到数据包
nginx-7d6877d777-zp5jg netns eth0 可以抓到数据包
数据链路转发示意图
不会经过分配给 pod 的附属网卡
不会经过任何宿主机 ECS 的网络空间的中间节点
整个链路是需要从客户端 pod 所属的 ENI 网卡出 ECS，再从目的 POD 所属的 ENI 网卡进入 ECS
整个请求链路是 ECS1 POD1 -> ECS1 eth1 -> VPC -> ECS1 eth2 -> ECS1 POD2
2.4 场景四：不同节点间 Pod 之间互访
环境
cn-hongkong.10.0.3.15 节点上存在 nginx-7d6877d777-j7dqz， IP 分为 10.0.3.38
cn-hongkong.10.0.3.93 节点上存在 centos-6c48766848-dz8hz， IP 分为 10.0.3.127
通过 此节点的 terway pod， 我们可以 利用 terway-cli show factory 的命令看到 nginx-7d6877d777-j7dqz IP 10.0.3.5 属于 cn-hongkong.10.0.3.15 上的 MAC 地址 为 00:16:3e:04:08:3a 的 ENI 网卡
通过 此节点的 terway pod， 我们可以 利用 terway-cli show factory 的命令看到 centos-6c48766848-dz8hz IP 10.0.3.127 属于 cn-hongkong.10.0.3.93 上的 MAC 地址 为 00:16:3e:02:20:f5 的 ENI 网卡
内核路由
centos-6c48766848-dz8hz IP 地址 10.0.3.127 ，该容器在宿主机表现的 PID 是 1720370，该容器网络命名空间有指向容器 eth0 的默认路由, 有且只有一条，说明 pod 访问所有地址都需要通过该默认路由
nginx-7d6877d777-j7dqz IP 地址 10.0.3.38 ，该容器在宿主机表现的 PID 是 329470，该容器网络命名空间有指向容器 eth0 的默认路由
ECS OS 内是通过 ipvlan 隧道的方式和 ECS 的附属 ENI eth1 建立的隧道，通过 mac 地址一样可以看到两个 pod 分配的 ENI 地址
centos-6c48766848-dz8hz
nginx-7d6877d777-j7dqz
小结：可以访问到目的端
此处不再对抓包进行展示，从客户端角度，数据流可以在 centos-6c48766848-dz8hz 的网络命名空间 eth0 ，以及 此 pod 所部署的 ECS 对应的 ENI eth1 上可以被捕获到；从服务端角度，数据流可以在 nginx-7d6877d777-j7dqz 的网络命名空间 eth0 ，以及 此 pod 所部署的 ECS 对应的 ENI eth1 上可以被捕获到。
数据链路转发示意图
不会经过任何宿主机 ECS 的网络空间的中间节点
整个链路是需要从客户端 pod 所属的 ENI 网卡出 ECS，再从目的 POD 所属的 ENI 网卡进入 ECS
整个请求链路是 ECS1 POD1 -> ECS1 ethx -> VPC -> ECS2 ethy -> ECS2 POD2
2.5 场景五：集群内 Pod 访问的 SVC ClusterIP（含 Terway 版本≥1.2.0，访问 ExternalIP），SVC 后端 Pod 和客户端 Pod 配属同一个 ENI
环境
cn-hongkong.10.0.3.15 节点上存在 nginx-7d6877d777-j7dqz 和 centos-6c48766848-znkl8 两个 pod， IP 分别为 10.0.3.38 和 10.0.3.5
通过 此节点的 terway pod， 我们可以 利用 terway-cli show factory 的命令看到 这两个 IP （10.0.3.5 和 10.0.3.38）都属于同一个 MAC 地址 00:16:3e:04:08:3a ，说明这两个 IP 属于同一个 ENI，进而可以推断出 nginx-7d6877d777-j7dqz 和 centos-6c48766848-znkl8 属于同一个 ENI 网卡
通过 describe svc 可以看到 nginx pod 被加入到了 svc nginx 的后端。SVC 的 CLusterIP 是 192.168.27.242。如果是集群内访问 External IP， 对于 Terway 版本≥ 1.20 来说，集群内访问 SVC 的 ClusterIP 或 External IP，整个链路架构是一致的，此小节不在针对 External IP 单独说明，统一用 ClusterIP 作为示例（Terway 版本＜ 1.20 情况下，访问 External IP，会在后续小节说明）。
内核路由
centos-6c48766848-znkl8 IP 地址 10.0.3.5，该容器在宿主机表现的 PID 是 2747933，该容器网络命名空间有指向容器 eth0 的默认路由, 有且只有一条，说明 pod 访问所有地址都需要通过该默认路由
nginx-7d6877d777-j7dqz IP 地址 10.0.3.38 ，该容器在宿主机表现的 PID 是 329470，该容器网络命名空间有指向容器 eth0 的默认路由
在 ACK 中，是利用 cilium 去调用 ebpf 的能力，可以通过下面的命令可以看到 nginx-7d6877d777-j7dqz 和 centos-6c48766848-znkl8 identity ID 分别是 634 和 1592
通过 centos-6c48766848-znkl8 pod，可以找到此 pod 所在的 ECS 的 Terway pod 为 terway-eniip-6cfv9，在 Terway Pod 中运行下面的 cilium bpf lb list | grep -A5 192.168.27.242 命令可以看到 ebpf 中对于 CLusterIP 192.168.27.242:80 记录的后端是 10.0.3.38:80 。这上述的一切都是通过 EBPF 记录到了 源端 Pod centos-6c48766848-znkl8 pod 的 tc 中。
通过以上，可以理论推断出，如果集群内的 pod 访问 SVC 的 CLusterIP or External IP 地址（Terway ≥ 1.20）， 数据流会在 pod 的网络命名空间内就被转化为相应的 SVC 的后端 pod IP 后，再被从 Pod 网络命名空间的 eth0 发出 pod，进入到 pod 所在的 ECS，然后通过 IPVLAN 隧道，转发到同 ECS 或通过相应的 ENI 出 ECS。也就是说，我们如果抓包，不管在 pod 内抓包还是在 ECS 抓包，都无法捕获到 SVC 的 IP，只能捕获到 Pod IP。
EBPF 技术让集群内访问避开了 ECS OS 内部的内核协议栈和减少了部分 Pod 内核协议栈，大大提高了网络性能和 Pod 密度，带来了不弱于 单独 ENI 的网络性能，但是此方式会对我们观测带来巨大的改变和影响。试想一下，如果您的集群内存在互相调用情况，这个调用的 IP 是 SVC 的 IP，加入此 SVC 后端所引用的 Pod 有几十上百个。源端 pod 调用时候出现问题，一般情况下报错是 ‘connect to <svc IP> failed’ 等类似信息，传统的抓包手段是在源端 Pod 内，目的 Pod， ECS 上等进行抓包，筛选 SVC IP 来串起来不同包之间的同一个数据流，可是 eBPF 情况下由于上述技术实现，造成无法捕获 SVC IP，是不是对偶发抖动情况下的观测带来了巨大挑战呢？
小结：可以访问到目的端
从客户端 Pod centos-6c48766848-znkl8 访问 SVC ， 我们可以看到访问成功
客户端的 centos-6c48766848-znkl8 网络命名空间内 eth0 抓包，抓包地址是目的 SVC 的 IP 和 SVC 的后端 POD IP。可以看到只能抓到 SVC 后端 Pod IP，无法捕获到 SVC IP。
目的端 SVC 的后端 POD nginx-7d6877d777-zp5jg 网络命名空间 eth0 抓包，抓包地址是目的 SVC 的 IP 和 客户端 POD IP。可以看到只能抓到客户端 Pod IP。
cilium 提供了一个 monitor 的功能，我们使用 cilium monitor --related-to <endpoint ID> ， 可以看到，源端 POD IP 访问 SVCIP 192.168.27.242， 之后被解析到 SVC 的后端 POD IP 10.0.3.38.，说明 SVC IP 直接在 tc 层做了转发，这也解释了为什么抓包无法抓到 SVC IP，因为抓包是在 netdev 上抓的，此时已经过了 协议栈和 tc。
后续小节如果涉及 SVC IP 的访问，如有类似，不再做详细的抓包展示
数据链路转发示意图
不会经过任何宿主机 ECS 的网络空间的中间节点
整个链路请求不会经过 pod 所分配的 ENI，直接在 OS 的 ns 中命中 Ip rule 被转发到对端 pod
整个请求链路是 ECS1 Pod1 -> ECS1 pod2 （发生在 ECS 内部）， 和 IPVS 相比，避免了 calico 网卡设备的两次转发，性能是更好的。
ECS1 Pod1 的 eth0 网卡无法捕捉到 SVC IP，SVC IP 在 pod 网络命名空间内已经通过 ebpf 转换成了 SVC 后端 Pod 的 IP
2.6 场景六：集群内 Pod 访问的 SVC ClusterIP（含 Terway 版本≥1.2.0，访问 ExternalIP），SVC 后端 Pod 和客户端 Pod 配属不同 ENI（同 ECS）
环境
cn-hongkong.10.0.3.15 节点上存在 nginx-7d6877d777-j7dqz 和 busybox-d55494495-8t677 两个 pod， IP 分别为 10.0.3.38 和 10.0.3.22
通过 此节点的 terway pod， 我们可以 利用 terway-cli show factory 的命令看到 这两个 IP （10.0.3.22 和 10.0.3.38）都属于同一个 MAC 地址 00:16:3e:01:b7:bd 和 00:16:3e:04:08:3a ，说明这两个 IP 属于不同 ENI，进而可以推断出 nginx-7d6877d777-j7dqz 和 busybox-d55494495-8t677 属于不同 ENI 网卡
通过 describe svc 可以看到 nginx pod 被加入到了 svc nginx 的后端。SVC 的 CLusterIP 是 192.168.27.242。如果是集群内访问 External IP， 对于 Terway 版本≥ 1.20 来说，集群内访问 SVC 的 ClusterIP 或 External IP，整个链路架构是一致的，此小节不在针对 External IP 单独说明，统一用 ClusterIP 作为示例（Terway 版本＜ 1.20 情况下，访问 External IP，会在后续小节说明）。
内核路由
busybox-d55494495-8t677 IP 地址 10.0.3.22 ，该容器在宿主机表现的 PID 是 2956974，该容器网络命名空间有指向容器 eth0 的默认路由, 有且只有一条，说明 pod 访问所有地址都需要通过该默认路由
nginx-7d6877d777-j7dqz IP 地址 10.0.3.38 ，该容器在宿主机表现的 PID 是 329470，该容器网络命名空间有指向容器 eth0 的默认路由
在 ACK 中，是利用 cilium 去调用 ebpf 的能力，可以通过下面的命令可以看到 nginx-7d6877d777-j7dqz 和 busybox-d55494495-8t677 identity ID 分别是 634 和 3681
通过 busybox-d55494495-8t677 pod，可以找到此 pod 所在的 ECS 的 Terway pod 为 terway-eniip-6cfv9，在 Terway Pod 中运行下面的 cilium bpf lb list | grep -A5 192.168.27.242 命令可以看到 ebpf 中对于 CLusterIP 192.168.27.242:80 记录的后端是 10.0.3.38:80 。这上述的一切都是通过 EBPF 记录到了 源端 Pod centos-6c48766848-znkl8 pod 的 tc 中。
这里不再过多对于 svc ClusterIP 的 ebpf 转发进行描述，详细信息可以参考 2.5 小节中的描述，从上述描述情况，可以得知被访问的 SVC 的 IP 在 客户端 busybox 的网络命名空间中已经被 ebpf 转为 svc 的后端 pod 的 IP，在任何 dev 上都无法捕获到客户端访问的 SVC 的 IP。故此场景和 2.3 小节的网络架构非常类似，只是在客户端内会由 cilium ebpf 转发的动作
小结
数据链路转发示意图
不会经过任何宿主机 ECS 的网络空间的中间节点
整个链路是需要从客户端 pod 所属的 ENI 网卡出 ECS 再从目的 POD 所属的 ENI 网卡进入 ECS
整个请求链路是 ECS1 POD1 -> ECS1 eth1 -> VPC -> ECS1 eth2 -> ECS1 POD2
在客户端/服务端 Pod 内或者 ECS 的 ENI 网卡都 无法捕捉到 SVC IP，SVC IP 在 客户端 pod 网络命名空间内已经通过 ebpf 转换成了 SVC 后端 Pod 的 IP
2.7 场景七：集群内 Pod 访问的 SVC ClusterIP，SVC 后端 Pod 和客户端 Pod 不属于不同 ECS
环境
cn-hongkong.10.0.3.15 节点上存在 nginx-7d6877d777-j7dqz， IP 分为 10.0.3.38cn-hongkong.10.0.3.93 节点上存在 centos-6c48766848-dz8hz， IP 分为 10.0.3.127
通过 此节点的 terway pod， 我们可以 利用 terway-cli show factory 的命令看到 nginx-7d6877d777-j7dqz IP 10.0.3.5 属于 cn-hongkong.10.0.3.15 上的 MAC 地址 为 00:16:3e:04:08:3a 的 ENI 网卡
通过 此节点的 terway pod， 我们可以 利用 terway-cli show factory 的命令看到 centos-6c48766848-dz8hz IP 10.0.3.127 属于 cn-hongkong.10.0.3.93 上的 MAC 地址 为 00:16:3e:02:20:f5 的 ENI 网卡
通过 describe svc 可以看到 nginx pod 被加入到了 svc nginx 的后端。SVC 的 CLusterIP 是 192.168.27.242。如果是集群内访问 External IP， 对于 Terway 版本≥ 1.20 来说，集群内访问 SVC 的 ClusterIP 或 External IP，整个链路架构是一致的，此小节不在针对 External IP 单独说明，统一用 ClusterIP 作为示例（Terway 版本＜ 1.20 情况下，访问 External IP，会在后续小节说明）。
内核路由
Pod 访问 SVC 的 Cluster IP，而 SVC 的后端 Pod 和 客户端 Pod 部署在不同 ECS 上，此架构类似 2.4 小节中的不同 ECS 节点上的 Pod 间互访情况，只不此场景是 Pod 访问 SVC 的 ClusterIP，要注意此处是访问 ClusterIP，如果是访问 External IP，那么场景会进一步复杂了，本门的后面几个小节会详细说明。对于 ClusterIP 的 ebpf 转发进行描述，详细信息可以参考 2.5 小节中的描述，和前面几个小节一样，在任何 dev 上都无法捕获到客户端访问的 SVC 的 IP。
小结
数据链路转发示意图
不会经过任何宿主机 ECS 的网络空间的中间节点
整个链路是需要从客户端 pod 所属的 ENI 网卡出 ECS 再从目的 POD 所属的 ENI 网卡进入 ECS
整个请求链路是 ECS1 POD1 -> ECS1 eth1 -> VPC -> ECS2 eth1 -> ECS2 POD2
在客户端/服务端 Pod 内或者 ECS 的 ENI 网卡都 无法捕捉到 SVC IP，SVC IP 在 客户端 pod 网络命名空间内已经通过 ebpf 转换成了 SVC 后端 Pod 的 IP
2.8 场景八：集群内 Pod 访问的 SVC ExternalIP（Terway 版本≤1.2.0），SVC 后端 Pod 和客户端 Pod 配属同一个 ENI
环境
此处环境和 2.5 小节 情况类似，不做过多描述，只是此小节是在 terway 版本小于 1.2.0 情况下，访问 External IP 47.243.139.183
内核路由
请参考 2.5 小节。
由于客户端 Pod 和被访问的 SVC 的后端 Pod 同属于同一个 ENI，那么在 terway 版本小于 1.2.0 的情况下，访问 External IP，实际上数据链路会通过 ENI 出 ECS 到 External IP 的 SLB，在被转发到同一个 ENI 上。四层 SLB 目前是不支持同一个 EI 同时作为客户端和服务端，所以会形成回环，详细信息可以参考下面连接：https://help.aliyun.com/document_detail/97467.html#section-krj-kqf-14s
https://help.aliyun.com/document_detail/55206.htm
小结
数据链路转发示意图
整个请求链路是 ECS1 POD1 -> ECS1 eth1 -> VPC -> SLB -> 中断
Terway 版本小于 1.2.0 时，集群内访问 external IP，会出 ECS ENI 到 SLB，再由 SLB 转发到 ECS ENI 上，如果源 pod 所属的 ENI 和被转发的 ENI 为同一个，将访问不成功，原因是四层 SLB 会形成回环
解决方案（任何一个）：
通过 SVC annotation 将 SLB 配置为 7 层监听
将 Terway 版本升级之 1.2.0 以及上，并开启集群内负载均衡。Kube-Proxy 会短路集群内访问 ExternalIP、LoadBalancer 的流量，即集群内访问这些外部地址，实际流量不会到外部，而会被转为对应后端的 Endpoint 直接访问。在 Terway IPvlan 模式下，Pod 访问这些地址流量由 Cilium 而不是 kube-proxy 进行处理， 在 Terway v1.2.0 之前版本并不支持这种链路的短路。在 Terway v1.2.0 版本发布后，新建集群将默认开启该功能，已创建的集群不会开启。（此处就是 2.5 小节场景）https://help.aliyun.com/document_detail/197320.htm
https://help.aliyun.com/document_detail/113090.html#p-lim-520-w07
2.9 场景九：集群内 Pod 访问的 SVC ExternalIP（Terway 版本≤1.2.0），SVC 后端 Pod 和客户端 Pod 配属不同 ENI（同 ECS）
环境
此处环境和 2.6 小节 情况类似，不做过多描述，只是此小节是在 terway 版本小于 1.2.0 情况下，访问 External IP 47.243.139.183
内核路由
请参考 2.6 和 2.8 小节。
由于客户端 Pod 和被访问的 SVC 的后端 Pod 虽然同属于同一个 ECS，但是不属于同一个 ENI，那么在 terway 版本小于 1.2.0 的情况下，访问 External IP，实际上数据链路会通过客户端 pod ENI 出 ECS 到 External IP 的 SLB，在被转发到另一个一个 ENI 上。虽然从外部感知上看 两个客户端 Pod 和 SVC 的后端 Pod 都是在同一个 ECS，但是由于属于不同 ENI，所以不会形成回环，可以访问成功，此处的结果和 2.8 小节完全不同，需要注意。
小结
数据链路转发示意图
整个请求链路是 ECS1 POD1 -> ECS1 eth1 -> VPC -> SLB -> ECS1 eth2 -> ECS1 POD2
Terway 版本小于 1.2.0 时，集群内访问 external IP，会出 ECS ENI 到 SLB，再由 SLB 转发到 ECS ENI 上，如果源 pod 所属的 ENI 和被转发的 ENI 为同一个，将访问不成功，原因是四层 SLB 会形成回环
如果源 pod 所属的 ENI 和被转发的 ENI 为是同一个节点上的不同 ENI，可以访问成功
2.10 场景十：集群内 Pod 访问的 SVC ExternalIP（Terway 版本≤1.2.0），SVC 后端 Pod 和客户端 Pod 部署于不同 ECS
环境
此处环境和 2.6 小节 情况类似，不做过多描述，只是此小节是在 terway 版本小于 1.2.0 情况下，访问 External IP 47.243.139.183
内核路由
请参考 2.7 和 2.9 小节。
此处和 2.7 的架构场景相似，都是客户端 Pod 和 SVC 的后端 Pod 不属于不同的 ECS 节点， 客户端去访问 SVC 的 External IP。只有 Terway 的版本不同，2.7 小节 Terway 版本是≥1.2.0，此小节是＜1.2.0，仅仅是 Terway 版本和 eniconfig 的不同，两者访问链路一个会经过 SLB，一个则不会经过 SLB，这一点需要关注。置于不同的原因是因为 1.2.0 Terway 版本之后开启集群内负载均衡，对于访问 ExternalIP 会被负载到 Service 网段，具体信息请见 2.8 小节。
小结
数据链路转发示意图
整个请求链路是 ECS1 POD1 -> ECS1 eth1 -> VPC -> SLB -> ECS2 eth1 -> ECS2 POD2
Terway 版本小于 1.2.0 时，集群内访问 external IP，会出 ECS ENI 到 SLB，再由 SLB 转发到 ECS ENI 上，如果源 pod 所属的 ENI 和被转发的 ENI 为同一个，将访问不成功，原因是四层 SLB 会形成回环
2.11 场景十一：集群外访问 SVC ExternalIP
环境
cn-hongkong.10.0.3.15 节点上存在 nginx-7d6877d777-j7dqz， IP 分为 10.0.3.34 通过 describe svc 可以看到 nginx pod 被加入到了 svc nginx 的后端。SVC 的 CLusterIP 是 192.168.27.242。
内核路由
在 SLB 控制台，可以看到 lb-j6cj07oi6uc705nsc1q4m 虚拟服务器组的后端服务器组是两个后端 nginx pod 的的 ENI eni-j6cgs979ky3evp81j3n8
从集群外部角度看，SLB 的后端虚拟服务器组是 SVC 的后端 Pod 所属的 ENI 网卡，内网的 IP 地址就是 Pod 的地址
小结
数据链路转发示意图
ExternalTrafficPolicy 为 Local 或 Cluster 模式下， SLB 只会将 pod 分配的 ENI 挂在到 SLB 的虚拟服务器组
数据链路：client -> SLB -> Pod ENI + Pod Port -> ECS1 Pod1 eth0
总结
本篇文章主要聚焦 ACK 在 Terway IPVLAN+EBPF 模式下，不同 SOP 场景下的数据链路转发路径。伴随着客户对性能极致追求的需求，在 Terway IPVLAN+EBPF 相比 Terway ENI，有更高的 Pod 密度；相比 Terway ENIIP，有更高的性能，但因此也带了网络链路的复杂性和可观测性带来了调整，此场景可以分为 11 个 SOP 场景，并对这 11 个场景的转发链路，技术实现原理，云产品配置等一一梳理并总结，这对我们遇到 Terway IPVLAN 架构下的链路抖动、最优化配置，链路原理等提供了初步指引方向。在 Terway IPVLAN 模式下，利用 EBPF 和 IPVLAN 隧道，避免了数据链路在 ECS OS 内核协议栈的转发，这必然带来了更高的性能，同时也有 ENIIP 模式一样的多 IP 共享 ENI 的方式来保证 Pod 密度。但是随着业务场景越来越趋于复杂，业务的 ACL 管控也更加趋于 Pod 维度去管理，比如需要针对 Pod 维度进行安全 ACL 规则设置的需求等。下一系列我们将进入到 Terway ENI-Trunking 模式的全景解析——《ACK 全景剖析阿里云容器网络数据链路（五）—— Terway ENI-Trunking》。
点击此处查看阿里云容器服务
版权声明: 本文为 InfoQ 作者【阿里巴巴云原生】的原创文章。
原文链接:【http://xie.infoq.cn/article/f7531dd81261adbbd5e8fce9e】。文章转载请联系作者。
阿里云云原生 2019-05-21 加入
还未添加个人简介
评论