关于阿里云:全景剖析阿里云容器网络数据链路四Terway-IPVLANEBPF

本系列文章由余凯执笔创作，联结作者：阿里云容器服务谢石对本文亦有奉献

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

鸟瞰容器网络，整个容器网络能够分为三个局部：Pod网段，Service网段和Node网段。这三个网络要实现互联互通和访问控制，那么实现的技术原理是什么？整个链路又是什么，限度又是什么呢？Flannel， Terway有啥区别？不同模式下网络性能如何？这些，须要客户在下搭建容器之前，就要根据本人的业务场景进行抉择，而搭建结束后，相干的架构又是无奈转变，所以客户须要对每种架构特点要有充沛理解。比方下图是个简图，Pod网络既要实现同一个ECS的Pod间的网络互通和管制，又要实现不同ECS Pod间的拜访， Pod拜访SVC 的后端可能在同一个ECS 也可能是其余ECS，这些在不同模式下，数据链转发模式是不同的，从业务侧体现后果也是不一样的。

本文是[全景分析容器网络数据链路]第四局部局部，次要介绍Kubernetes Terway EBPF+IPVLAN模式下，数据面链路的转转发链路，一是通过理解不同场景下的数据面转发链路，从而探知客户在不同的场景下拜访后果体现的起因，帮忙客户进一步优化业务架构；另一方面，通过深刻理解转发链路，从而在遇到容器网络抖动时候，客户运维以及阿里云同学能够晓得在哪些链路点进行部署观测手动，从而进一步定界问题方向和起因。

系列一：全景分析阿里云容器网络数据链路（一）—— Flannel
系列二：全景分析阿里云容器网络数据链路（二）—— Terway ENI
系列三：全景分析阿里云容器网络数据链路（三）—— Terway ENIIP
系列五：全景分析阿里云容器网络数据链路（五）—— 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/Do...

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的数据包进行批改。

官网链接：
https://ebpf.io/what-is-ebpf/

例如，同上图，能够看到集群内有一个名为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容器网络：
https://help.aliyun.com/docum...

故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

通过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，会在后续大节阐明）。

内核路由

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

内核路由

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

![75.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/0eaf17b2ad0f4fd7bfc91461bcca7b89~tplv-k3u1fbpfcp-zoom-1.image "75.png")

这里不再过多对于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

内核路由

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/docum...

https://help.aliyun.com/docum...

小结

数据链路转发示意图

整个申请链路是 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/docum...

https://help.aliyun.com/docum...

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》。

点击此处查看阿里云容器服务