全景剖析阿里云容器网络数据链路(四)—— Terway IPVLAN+EBPF

简介: 本文是[全景剖析容器网络数据链路]第四部分部分,主要介绍Kubernetes Terway EBPF+IPVLAN模式下,数据面链路的转转发链路。

1. 前言

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

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

image

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

系列一:全景剖析阿里云容器网络数据链路(一)—— Flannel

系列二:全景剖析阿里云容器网络数据链路(二)—— Terway ENI

系列三:全景剖析阿里云容器网络数据链路(三)—— Terway ENIIP

系列四:全景剖析阿里云容器网络数据链路(四)—— Terway IPVLAN+EBPF

系列五:全景剖析阿里云容器网络数据链路(五)—— Terway ENI-Trunking

系列六:全景剖析阿里云容器网络数据链路(六)—— ASM Istio

2. 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策略路由较好。

image

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

image

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

Dingtalk_20230220102917  Dingtalk_20230220103032

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

Dingtalk_20230220103117

那么Pod是如何ECS OS进行通信呢?在OS层面,我们一看到ipvl_x的网卡,可以看到是附属于eth1的,说明在OS层面会给每个附属网卡创建一个ipvl_x的网卡,用于建立OS和Pod内的连接隧道。

image

ECS OS内对于数据流量是怎么判断去哪个容器呢? 通过OS Linux Routing 我们可以看到,所有目的是 Pod IP 的流量都会被转发到Pod对应的ipvl_x虚拟往卡上,到这里为止,ECS OS 和Pod的网络命名空间已经建立好完整的出入链路配置了。到目前为止介绍了IPVLAN在网络架构上实现了。

Dingtalk_20230220103207

对于eni多IP的实现,这个类似于《全景剖析阿里云容器网络数据链路(三)—— Terway ENIIP》 原理,Terway Pod是通过daemonset的方式部署在每个节点上的,通过下面命令可以看到每个节点上的Terway Pod。通过terway-cli show factory 命令可以看到节点上的附属ENI数量、MAC地址以及每个ENI上的IP

image

那么对于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的数据包进行修改。

image  image

例如,同上图,可以看到集群内有一个名为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容器网络可观测性工具,可以针对此场景进行持续化的观测和问题判断。

故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都无法被捕获到。

3. Terway IPVLAN+EBPF 模式容器网络数据链路剖析

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

image

对这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

3.1 场景一:访问Pod IP,同节点访问pod

环境

image

cn-hongkong.10.0.3.15 节点上存在 nginx-7d6877d777-j7dqz 和 10.0.3.38

内核路由

nginx-7d6877d777-j7dqz IP地址 10.0.3.38 ,该容器在宿主机表现的PID是329470,该容器网络命名空间有指向容器eth0的默认路由

image  Dingtalk_20230220103323

该容器eth0在ECS OS 内是通过ipvlan隧道的方式和ECS的附属ENI eth1建立的隧道,同时附属ENI eth1还有个虚拟的ipvl_8@eth1 网卡

Dingtalk_20230220103433

通过OS Linux Routing 我们可以看到,所有目的是 Pod IP 的流量都会被转发到Pod对应的ipvl_x虚拟往卡上,这样就建立完毕ECS和Pod之间的连接隧道了。

Dingtalk_20230220103533

小结

可以访问到目的端

nginx-7d6877d777-zp5jg netns eth0 可以抓到数据包

image

ECS 的 ipvl_8 可以抓到数据包

image

数据链路转发示意图:

image

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

  • 整个链路是通过查找路由表进入ipvl_xxx不需要经过ENI

  • 整个请求链路是node -> ipvl_xxx -> ECS1 Pod1

3.2 场景二:访问Pod IP,同节点pod间互访(pod属于同ENI)

环境

image

cn-hongkong.10.0.3.15 节点上存在 nginx-7d6877d777-j7dqz 和 centos-6c48766848-znkl8 两个pod, IP分别为 10.0.3.38 和 10.0.3.5

image

通过 此节点的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访问所有地址都需要通过该默认路由

image  image

nginx-7d6877d777-j7dqz IP地址 10.0.3.38 ,该容器在宿主机表现的PID是329470,该容器网络命名空间有指向容器eth0的默认路由

image  image

该容器eth0在ECS OS 内是通过ipvlan隧道的方式和ECS的附属ENI eth1建立的隧道,同时附属ENI eth1还有个虚拟的ipvl_8@eth1 网卡

image

小结

可以访问到目的端

centos-6c48766848-znkl8 netns eth0 可以抓到数据包

image

nginx-7d6877d777-zp5jg netns eth0 可以抓到数据包

image

ipvl_8 网卡 并没有捕获到相关的数据流量包

image

数据链路转发示意图:

Dingtalk_20230222101529

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

  • 不会经过任何宿主机ECS的网络空间的中间节点

  • 整个链路不会和请求不会经过pod所分配的ENI,直接在OS 的ns中命中 Ip rule 被转发到对端pod

  • 整个请求链路是 ECS1 Pod1 -> ECS1 pod2 (发生在ECS内部), 和IPVS相比,避免了calico网卡设备的两次转发,性能是更好的。

3.3 场景三:访问Pod IP,同节点pod间互访(pod属于不同ENI)

环境

image

cn-hongkong.10.0.3.15 节点上存在 nginx-7d6877d777-j7dqz 和 busybox-d55494495-8t677 两个pod, IP分别为 10.0.3.38 和 10.0.3.22

image

通过 此节点的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访问所有地址都需要通过该默认路由

image  image

nginx-7d6877d777-j7dqz IP地址 10.0.3.38 ,该容器在宿主机表现的PID是329470,该容器网络命名空间有指向容器eth0的默认路由

image  image

该容器eth0在ECS OS 内是通过ipvlan隧道的方式和ECS的附属ENI eth1建立的隧道,通过mac地址一样可以看到,nginx-7d6877d777-j7dqz 和 busybox-d55494495-8t677 分别被分配eth1和eth2

image

小结

可以访问到目的端

busybox-d55494495-8t677 netns eth0 可以抓到数据包

image

nginx-7d6877d777-zp5jg netns eth0 可以抓到数据包

image

数据链路转发示意图:

Dingtalk_20230222101238

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

  • 不会经过任何宿主机ECS的网络空间的中间节点

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

  • 整个请求链路是 ECS1 POD1 -> ECS1 eth1 -> VPC -> ECS1 eth2 -> ECS1 POD2

3.4 场景四:不同节点间Pod之间互访

环境

image

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

image

通过 此节点的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网卡

image

通过 此节点的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访问所有地址都需要通过该默认路由

image  image

nginx-7d6877d777-j7dqz IP地址 10.0.3.38 ,该容器在宿主机表现的PID是329470,该容器网络命名空间有指向容器eth0的默认路由

image  image

ECS OS 内是通过ipvlan隧道的方式和ECS的附属ENI eth1建立的隧道,通过mac地址一样可以看到两个pod 分配的ENI地址

centos-6c48766848-dz8hz

image

nginx-7d6877d777-j7dqz

image

小结

可以访问到目的端

此处不再对抓包进行展示,从客户端角度,数据流可以在centos-6c48766848-dz8hz 的网络命名空间 eth0 ,以及 此pod所部署的ECS 对应的ENI eth1上可以被捕获到;从服务端角度,数据流可以在nginx-7d6877d777-j7dqz 的网络命名空间 eth0 ,以及 此pod所部署的ECS对应的ENI eth1上可以被捕获到。

数据链路转发示意图:

image

  • 不会经过任何宿主机ECS的网络空间的中间节点

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

  • 整个请求链路是 ECS1 POD1 -> ECS1 ethx -> VPC -> ECS2 ethy -> ECS2 POD2

3.5 场景五:集群内Pod访问的SVC ClusterIP(含Terway版本≥1.2.0,访问ExternalIP),SVC后端Pod和客户端Pod配属同一个ENI

环境

image

cn-hongkong.10.0.3.15 节点上存在 nginx-7d6877d777-j7dqz 和 centos-6c48766848-znkl8 两个pod, IP分别为 10.0.3.38 和 10.0.3.5

image

通过 此节点的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,会在后续小节说明)。

image

内核路由

centos-6c48766848-znkl8 IP地址 10.0.3.5,该容器在宿主机表现的PID是2747933,该容器网络命名空间有指向容器eth0的默认路由, 有且只有一条,说明pod访问所有地址都需要通过该默认路由

image  image

nginx-7d6877d777-j7dqz IP地址 10.0.3.38 ,该容器在宿主机表现的PID是329470,该容器网络命名空间有指向容器eth0的默认路由

image  image

在ACK中,是利用cilium去调用ebpf的能力,可以通过下面的命令可以看到 nginx-7d6877d777-j7dqz 和 centos-6c48766848-znkl8 identity ID 分别是 634 和 1592

image

通过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中。

image  image

通过以上,可以理论推断出,如果集群内的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  failed’ 等类似信息,传统的抓包手段是在源端Pod内,目的Pod, ECS上等进行抓包,筛选 SVC IP 来串起来不同包之间的同一个数据流,可是ebpf情况下由于上述技术实现,造成无法捕获SVC IP,是不是对偶发抖动情况下的观测带来了巨大挑战呢?

小结

可以访问到目的端

从客户端Pod centos-6c48766848-znkl8 访问SVC , 我们可以看到访问成功

image

客户端的centos-6c48766848-znkl8 网络命名空间内 eth0 抓包,抓包地址是目的SVC 的IP 和 SVC 的后端POD IP。 可以看到只能抓到SVC 后端Pod IP,无法捕获到SVC IP。

image

目的端SVC的后端POD nginx-7d6877d777-zp5jg 网络命名空间 eth0 抓包,抓包地址是目的SVC 的IP 和 客户端 POD IP。 可以看到只能抓到客户端Pod IP。

image

cilium 提供了一个monitor的功能,我们使用cilium monitor --related-to  , 可以看到,源端POD IP 访问SVCIP 192.168.27.242, 之后被解析到SVC的后端POD IP 10.0.3.38.,说明SVC IP直接在tc层做了转发,这也解释了为什么抓包无法抓到SVC IP,因为抓包是在netdev上抓的,此时已经过了 协议栈和tc。

image

后续小节如果涉及SVC IP 的访问,如有类似,不再做详细的抓包展示

数据链路转发示意图:

image

  • 不会经过任何宿主机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

3.6 场景六:集群内Pod访问的SVC ClusterIP(含Terway版本≥1.2.0,访问ExternalIP),SVC后端Pod和客户端Pod配属不同ENI(同ECS)

环境

image

cn-hongkong.10.0.3.15 节点上存在 nginx-7d6877d777-j7dqz 和 busybox-d55494495-8t677 两个pod, IP分别为 10.0.3.38 和 10.0.3.22

image

通过 此节点的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,会在后续小节说明)。

image

内核路由

busybox-d55494495-8t677 IP地址 10.0.3.22 ,该容器在宿主机表现的PID是2956974,该容器网络命名空间有指向容器eth0的默认路由, 有且只有一条,说明pod访问所有地址都需要通过该默认路由

image  image

nginx-7d6877d777-j7dqz IP地址 10.0.3.38 ,该容器在宿主机表现的PID是329470,该容器网络命名空间有指向容器eth0的默认路由

image  image

在ACK中,是利用cilium去调用ebpf的能力,可以通过下面的命令可以看到 nginx-7d6877d777-j7dqz 和 busybox-d55494495-8t677 identity ID 分别是 634 和 3681

image

通过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中。

image  image

这里不再过多对于svc ClusterIP的ebpf转发进行描述,详细信息可以参考 2.5 小节中的描述,从上述描述情况,可以得知被访问的SVC 的IP 在 客户端 busybox 的网络命名空间中已经被ebpf转为svc 的后端pod 的IP,在任何dev上都无法捕获到客户端访问的SVC的IP。 故此场景和 2.3 小节的网络架构非常类似,只是在客户端内会由cilium ebpf转发的动作

小结

数据链路转发示意图:

image

  • 不会经过任何宿主机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

3.7 场景七:集群内Pod访问的SVC ClusterIP,SVC后端Pod和客户端Pod不属于不同ECS

环境

image

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

image

通过 此节点的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网卡

image

通过 此节点的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,会在后续小节说明)。

image

内核路由

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。

小结

数据链路转发示意图:

image

  • 不会经过任何宿主机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

3.8 场景八:集群内Pod访问的SVC ExternalIP(Terway版本≤1.2.0),SVC后端Pod和客户端Pod配属同一个ENI

环境

此处环境和 2.5小节 情况类似,不做过多描述,只是此小节是在terway 版本小于1.2.0 情况下,访问External IP 47.243.139.183

image

内核路由

请参考2.5 小节。

由于客户端Pod和被访问的SVC的后端Pod同属于同一个ENI,那么在terway 版本小于1.2.0 的情况下,访问External IP,实际上数据链路会通过ENI出ECS到External IP 的SLB,在被转发到同一个ENI上。四层SLB目前是不支持同一个EI同时作为客户端和服务端,所以会形成回环,详细信息可以参考下面链接:

链接1

链接2

小结

数据链路转发示意图:

image

  • 整个请求链路是 ECS1 POD1 -> ECS1 eth1 -> VPC -> SLB -> 中断

  • Terway版本小于1.2.0时,集群内访问external IP,会出ECS ENI到SLB,再由SLB转发到ECS ENI上,如果源pod所属的ENI和被转发的ENI为同一个,将访问不成功,原因是四层SLB会形成回环

  • 解决方案(任何一个):

  1. 通过SVC annotation将SLB配置为7层监听

  2. 将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小节场景)

链接1

链接2

3.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

image

内核路由

请参考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 小节完全不同,需要注意。

小结

数据链路转发示意图:

image

  • 整个请求链路是 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,可以访问成功

3.10 场景十:集群内Pod访问的SVC ExternalIP(Terway版本≤1.2.0),SVC后端Pod和客户端Pod部署于不同ECS

环境

此处环境和 2.6小节 情况类似,不做过多描述,只是此小节是在terway 版本小于1.2.0 情况下,访问External IP 47.243.139.183

image

内核路由

请参考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 小节。

小结

数据链路转发示意图:

image

  • 整个请求链路是 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会形成回环

3.11 场景十一:集群外访问SVC ExternalIP

环境

image

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。

image

内核路由

在SLB控制台,可以看到 lb-j6cj07oi6uc705nsc1q4m 虚拟服务器组的后端服务器组是两个后端nginx pod 的的ENI eni-j6cgs979ky3evp81j3n8

image

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

小结

数据链路转发示意图:

image

  • ExternalTrafficPolicy 为Local或Cluster模式下, SLB只会将 pod分配的ENI挂在到SLB的虚拟服务器组

  • 数据链路:client -> SLB -> Pod ENI + Pod Port -> ECS1 Pod1 eth0

4. 总结

本篇文章主要聚焦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模式的全景解析——《全景剖析阿里云容器网络数据链路(五)—— Terway ENI-Trunking》。


本系列联合作者 容器服务 @谢石

作者介绍
目录