本系列文章由余凯执笔创造，联合作者：阿里云容器服务谢石 对本文亦有贡献
近几年，企业基础设施云原生化的趋势越来越激烈，从最开始的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：
www.kernel.org/doc/Documen…
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的完成，这个类似于《全景分析阿里云容器网络数据链路（三）——TerwayENIIP》原理，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的数据包进行修改。
官方链接：
ebpf.io/what-is-ebp…
例如，同上图，能够看到集群内有一个名为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共创了ACKNet-Exporter容器网络可观测性东西，能够针对此场景进行持续化的观测和问题判别。
ACK Net-Exporter容器网络：
help.aliyun.com/document_de…
故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 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 ， 能够看到，源端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一起作为客户端和服务端，所以会构成回环，具体信息能够参阅下面衔接：help.aliyun.com/document_de…
help.aliyun.com/document_de…
小结
数据链路转发示意图
-
整个恳求链路是 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末节场景）help.aliyun.com/document_de…
help.aliyun.com/document_de…
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》。
点击此处检查阿里云容器服务
