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

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

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

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

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

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

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

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

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

系列六：全景分析阿里云容器网络数据链路（六）—— ASM Istio (To be continued)

Terway ENI-Trunking 模式架构设计

弹性网卡中继Trunk ENI是一种能够绑定到专有网络VPC类型ECS实例上的虚构网卡。相比弹性网卡ENI，Trunk ENI的实例资源密度显著晋升。启用Terway Trunk ENI性能后，指定的Pod将应用Trunk ENI资源。为Pod开启自定义配置是可选性能，默认状况下创立的Pod，未开启Terway Trunk ENI性能，应用的是共享ENI上的IP地址。只有当您被动申明为指定Pod开启自定义配置后，相应的Pod能力应用Pod自定义配置能力，Terway才能够同时应用共享ENI以及Trunk ENI为Pod调配IP。两种模式共享节点最大Pod数量配额，总部署密度和开启前统一。

金融、电信，政府等行业对数据信息安全有着十分严格的数据安全要求，通常，重要的外围数据会放在自建的机房内，并且对拜访此数据的客户端有严格的白名单管制，通常会限度具体的IP拜访源。业务架构上云时，往往是通过专线，VPN等买通自建机房和云上资源买通，因为传统容器中PodIP 是不固定的，NetworkPolicy 只能在集群内失效，这对客户的白名单设置有了十分大的挑战。ENI 在 Trunk 模式下，能够配置独立的平安组、vSwitch能力，带来更为细化的网络配置能力，提供极具竞争力的容器网络解决方案。

在trunking的命名空间内能够看到相干的pod信息和节点信息，其中pod利用的IP 的网络咱们稍后会具体阐明

Pod内有只有指向eth0的默认路由，阐明Pod拜访任何地址段都是从eth0为对立的出入口

那么Pod是如何ECS OS进行通信呢？在OS层面，咱们一看到calicxxxx的网卡，能够看到是从属于eth1的，对于节点和Pod的通信连贯，这个相似于《全景分析阿里云容器网络数据链路（三）—— Terway ENIIP》，此处不再进行过多阐明。通过OS Linux Routing 咱们能够看到，所有目标是 Pod IP 的流量都会被转发到Pod对应的calico虚构往卡上，到这里为止，ECS OS 和Pod的网络命名空间曾经建设好残缺的出入链路配置了。

让咱们把眼光聚焦ENI Trunking自身。ENI Truning 是如何实现Pod的交换机和平安组的配置呢？Terway减少一种名为PodNetworking的自定义资源来形容网络配置。您能够创立多个PodNetworking，来布局不同网络立体。创立PodNetworking资源后，Terway将同步网络配置信息，只有status成为Ready后，该网络资源能力对Pod失效。如下图所示，类型为Elastic，只有namespce的标签的合乎tryunking：zoneb，就给pod应用指定的平安组和交换机。

创立Pod时，Pod将通过标签去匹配PodNetworking。如果Pod没有匹配到任何PodNetworking，则Pod将应用默认的共享ENI上的IP。如果Pod有匹配到PodNetworking，则将应用PodNetworking中定义的配置调配ENI。对于Pod标签的相干内容，请参见标签。

Terway会为这类Pod创立相应的名为PodENI的自定义资源，用于跟踪Pod所应用的资源，该资源由Terway治理，您不可批改该资源。如下trunking 命名空间下的centos-59cdc5c9c4-l5vf9 pod匹配了相应的podnetworking设置，被调配了相应的memeber ENI、对应的Trunking ENI，平安组，交换机和被绑定的ECS实例，这样就实现了Pod维度的交换机，平安组的配置和治理。

通过ECS的控制台，咱们也能够分明的看到memenber ENI和Trunking ENI 之间的关系，相应的平安组交换机等等信息。

通过下面的配置，咱们理解如何去给每个Pod独自配置交换机，平安组等信息，让每个pod在通过Trunking ENI出ECS后，能够主动走到对应的配置Member ENI 上，让这些配置失效。那么所有的配置其实落到宿主机上都是通过相干的策略实现的，Trunking ENi网卡是如何晓得把对应Pod的流量转发到正确的对应的Member ENI上的呢？这其实通过的vlan来实现的。在tc层面能够看到VLAN ID。所以在egress或者ingress的阶段会打上或者去除VLAN ID。

故Terway ENI-Trunking 模式总体能够演绎为：

弹性网卡中继Trunk ENI是一种能够绑定到专有网络VPC类型ECS实例上的虚构网卡。相比弹性网卡ENI，Trunk ENI的实例资源密度显著晋升
Terway Trunk ENI反对为每个Pod配置固定IP、独立的虚构交换机、平安组，能提供精细化流量治理、流量隔离、网络策略配置和IP治理能力。
应用Terway插件，您须要抉择较高规格和较新类型的ECS神龙机型，即5代或者6代的8核以上机型，且机型要反对Trunk ENI。更多信息，请参见实例规格族。
单节点所反对的最大Pod数取决于该节点的弹性网卡（ENI）数。共享ENI反对的最大Pod数=（ECS反对的ENI数-1）×单个ENI反对的公有IP数。
Pod平安组规定不会利用到同节点Pod间流量及同节点上节点与Pod间流量。如果您须要限度，能够通过NetworkPolicy进行配置。
Pod和对应MemeberENI流量对应是通过VLAN ID 来实现的。

Terway ENI-Trunking 模式容器网络数据链路分析

能够看到因为能够实现Pod维度的平安组，交换机设置，那么宏观上不同链路拜访必然更加趋于简单，咱们能够将Terway ENI-TRunking模式下的网络链路大体分为以Pod IP对外提供服务和以SVC对外提供服务两个大的SOP场景，进一步细分，能够演绎为10个不同的小的SOP场景。

对这11个场景的数据链路梳理合并，这些场景能够演绎为上面10类典型的场景：

通节点拜访Pod（雷同or不同平安组）
同节点同平安组Trunk Pod互访（含拜访SVC IP，源端和svc后端部署在同一节点）
同节点不同平安组Trunk Pod互访（含拜访SVC IP，源端和svc后端部署在同一节点）
不同节点同平安组Trunk Pod互访
不同节点不同平安组Trunk Pod互访
集群内源端拜访SVC IP（源端和SVC后端不同节点，雷同平安组，含Local模式拜访external IP）
集群内源端拜访SVC IP（源端和SVC后端不同节点，不同平安组，含Local模式拜访external IP）
Cluster模式下，集群内源端拜访SVC ExternalIP（源端和SVC后端不同节点，不同平安组）
Cluster模式下，集群内源端拜访SVC ExternalIP（源端和SVC后端不同节点，雷同平安组）
集群外拜访SVC IP

2.1 场景一：通节点拜访Pod（雷同or不同平安组）

环境

cn-hongkong.10.0.4.22 节点上存在 nginx-6f545cb57c-kt7r8和 10.0.4.30

内核路由

nginx-6f545cb57c-kt7r8 IP地址 10.0.4.30 ，该容器在宿主机体现的PID是1734171，该容器网络命名空间有指向容器eth0的默认路由

该容器eth0在ECS OS 内是通过ipvlan隧道的形式和ECS的从属ENI eth1建设的隧道，同时从属ENI eth1还有个虚构的calxxx 网卡

在ECS OS内，有指向Pod IP，下一跳为为calixxxx的路由，通过前文能够晓得calixxx网卡是和每个pod内的veth1组成的pair，所以，pod内拜访SVC的CIDR会有指向veth1的路由，不会走默认的eth0路由。故：calixx网卡在这里的次要作用是用于：1. 节点拜访Pod 2. 当节点或者Pod拜访 SVC的CIDR时，会走ECS OS内核协定栈转换，走到calixxx和veth1拜访pod。

trunking 命名空间下的nginx-6f545cb57c-kt7r8 pod匹配了相应的podnetworking设置，被调配了相应的memeber ENI、对应的Trunking ENI，平安组，交换机和被绑定的ECS实例，这样就实现了Pod维度的交换机，平安组的配置和治理。

在tc层面能够看到VLAN ID 1027，所以数据流量在egress或者ingress的阶段会打上或者去除VLAN ID。

ENI的网卡所属的平安组能够看到只容许了指定的IP能够拜访nginx pod的80 端口。

置于数据面流量在OS层面的流量转发逻辑，这个相似于《全景分析阿里云容器网络数据链路（三）—— Terway ENIIP》，不在这里做过多的叙述。

小结

能够拜访到目标端

数据链路转发示意图

会通过calicao网卡，每个非hostnetwork的pod会和calicao网卡造成veth pair，用于和其余pod或node进行通信
整个链路不会和申请不会通过pod所调配的ENI，间接在OS的ns中命中Ip rule 被转发1、
整个申请链路是 ECS1 OS -> calixxxx -> ECS1 Pod1
因为是通过 os内核routing转发，不通过 member eni，所以平安组不失效，此链路与pod所属的member eni的平安组无关

2.2 场景二：同节点同平安组Trunk Pod互访（含拜访SVC IP，源端和svc后端部署在同一节点）

环境

cn-hongkong.10.0.4.22 节点上存在 nginx-6f545cb57c-kt7r8，10.0.4.30和busybox-87ff8bd74-g8zs7，10.0.4.24。

内核路由

nginx-6f545cb57c-kt7r8 IP地址 10.0.4.30 ，该容器在宿主机体现的PID是1734171，该容器网络命名空间有指向容器eth0的默认路由

该容器eth0在ECS OS 内是通过ipvlan隧道的形式和ECS的从属ENI eth1建设的隧道，同时从属ENI eth1还有个虚构的calixxxx 网卡

trunking 命名空间下的busybox-87ff8bd74-g8zs7 和 nginx-6f545cb57c-kt7r8 pod匹配了相应的podnetworking设置，被调配了相应的memeber ENI、对应的Trunking ENI，平安组，交换机和被绑定的ECS实例，这样就实现了Pod维度的交换机，平安组的配置和治理。

在tc层面能够看到VLAN ID 1027，所以数据流量在egress或者ingress的阶段会打上或者去除VLAN ID。

ENI的网卡所属的平安组能够看到只容许了指定的IP能够拜访nginx pod的80 端口。

置于数据面流量在OS层面的流量转发逻辑，这个相似于《全景分析阿里云容器网络数据链路（三）—— Terway ENIIP》，不在这里做过多的叙述。

小结

能够拜访到目标端

数据链路转发示意图

会通过calicao网卡，每个非hostnetwork的pod会和calicao网卡造成veth pair，用于和其余pod或node进行通信
整个链路不会和申请不会通过pod所调配的ENI，间接在OS 的ns中命中 Ip rule 被转发
整个申请链路是ECS1 Pod1 eth0 -> cali1xxxxxx-> cali2xxxxxx -> ECS1 Pod2 eth0
pod属于同or不同 ENI，链路申请是统一的，不通过ENI
因为是通过 os内核 routing 转发，不通过 member eni，所以平安组不失效，此链路与pod所属的member eni的平安组无关
拜访Pod IP 和拜访 SVC IP（external ipor clusterip）的区别是:

拜访SVC IP， SVC 会在源端pod eth0和calixxx网卡捕捉到，在目标端pod的eth0和calixxx时捕获不到

2.3 场景三：同节点不同平安组Trunk Pod互访（含拜访SVC IP，源端和svc后端部署在同一节点）

环境

cn-hongkong.10.0.4.244 节点上存在 nginx-96bb9b7bb-wwrdm，10.0.5.35 和centos-648f9999bc-nxb6l，10.0.5.18。

内核路由

相干的Pod的容器网络命名空间，路由等不在进行过多形容，详情能够见后面两大节。

通过podeni能够看到centos-648f9999bc-nxb6l 所调配的ENI，平安组sg，交换机vsw等.

通过平安组sg-j6ccrxxxx能够看到centos 的pod能够拜访内部所有的地址

同理，能够查看出服务端Pod的nginx-96bb9b7bb-wwrdm 的平安组 sg-j6ccrze8utxxxxx 是只容许192.168.0.0/16 能够拜访

小结

能够拜访到目标端

数据链路转发示意图

会通过calicao网卡，每个非hostnetwork的pod会和calicao网卡造成veth pair，用于和其余pod或node进行通信
整个链路不会和申请不会通过pod所调配的ENI，间接在OS 的ns中命中 Ip rule 被转发
整个申请链路是ECS1 Pod1 eth0 -> cali1xxxxxx-> cali2xxxxxx -> ECS1 Pod2 eth0
pod属于同or不同 ENI，链路申请是统一的，不通过ENI
因为是通过 os内核 routing 转发，不通过 member eni，所以平安组不失效，此链路与pod所属的member eni的平安组无关
拜访Pod IP 和拜访 SVC IP（external ipor clusterip）的区别是:

拜访SVC IP， SVC 会在源端pod eth0和calixxx网卡捕捉到，在目标端pod的eth0和calixxx时捕获不到

2.4 场景四：不同节点同平安组Trunk Pod互访

环境

cn-hongkong.10.0.4.20 节点上存在客户端 centos-59cdc5c9c4-l5vf9 和IP 10.0.4.27

cn-hongkong.10.0.4.22 节点上存在服务端 nginx-6f545cb57c-kt7r8 和IP 10.0.4.30

内核路由

相干的Pod的容器网络命名空间，路由等不在进行过多形容，详情能够见后面两大节。通过podeni能够看到centos-59cdc5c9c4-l5vf9 所调配的ENI，平安组sg，交换机vsw等.

通过平安组sg-j6cf3sxrlbuwxxxxx能够看到centos和nginx的的pod属于同一个平安组 sg-j6cf3sxrlbuxxxxx。

小结

是否能够拜访取决于平安组配置

数据链路转发示意图

会通过calicao网卡，每个非hostnetwork的pod会和calicao网卡造成veth pair，用于和其余pod或node进行通信
整个链路不会和申请不会通过pod所调配的ENI，间接在OS 的ns中命中 Ip rule 被转发
出ECS后，依据要拜访的pod和该pod ENI所属vswitch，命中VPC路由规定或者间接VSW上的二层转发；
整个申请链路是 ECS1 Pod1 eth0 -> cali1xxx > Trunk eni ( ECS1) -> Pod1 member eni -> vpc route rule(如有) -> Pod2 member eni -> > Trunk eni ( ECS2) cali2 xxx -> ECS2 Pod1 eth0
因为是通过os内核 routing 转发，通过 member eni，因为member eni属于同一个平安组，所以平安组内默认是互通的

2.5 场景五：不同节点不同平安组Trunk Pod互访

环境

cn-hongkong.10.0.4.20 节点上存在客户端 centos-59cdc5c9c4-l5vf9 和IP 10.0.4.27

cn-hongkong.10.0.4.244 节点上存在服务端 nginx-96bb9b7bb-wwrdm 和IP 10.0.5.35

内核路由

相干的Pod的容器网络命名空间，路由等不在进行过多形容，详情能够见后面两大节。通过podeni能够看到centos-59cdc5c9c4-l5vf9 所调配的ENI，平安组sg，交换机vsw等。

通过平安组sg-j6cf3sxrlbuwxxxxx能够看到centos 的pod能够拜访内部所有的地址

同理，能够查看出服务端Pod的nginx-96bb9b7bb-wwrdm 的平安组 sg-j6ccrze8utxxxxx 是只容许192.168.0.0/16 能够拜访

小结

是否能够拜访取决于平安组配置

数据链路转发示意图

会通过calicao网卡，每个非hostnetwork的pod会和calicao网卡造成veth pair，用于和其余pod或node进行通信
整个链路不会和申请不会通过pod所调配的ENI，间接在OS 的ns中命中 Ip rule 被转发
整个申请链路是ECS1 Pod1 eth0 -> cali1xxx > Trunk eni ( ECS1) -> Pod1 member eni -> vpc route rule(如有) -> Pod2 member eni -> > Trunk eni ( ECS2) cali2 xxx -> ECS2 Pod1 eth0
因为是通过os内核routing转发，流量会通过member eni，是否能够拜访胜利，平安组配置对此有着决定性的作用。

2.6 场景六：集群内源端拜访SVC IP（源端和SVC后端不同节点，雷同平安组，含Local模式拜访external IP）

环境

cn-hongkong.10.0.4.20 节点上存在客户端 centos-59cdc5c9c4-l5vf9 和IP 10.0.4.27cn-hongkong.10.0.4.22 节点上存在服务端 nginx-6f545cb57c-kt7r8 和IP 10.0.4.30

nginx 的svc的ClusterIP是 192.168.81.92 External IP是 8.210.162.178

内核路由

ENI-Trunking相比拟ENIIP来说，只是在VPC侧减少了对应的Truning和Member ENI，在OS内并无区别，此处能够参考《全景分析阿里云容器网络数据链路（三）—— Terway ENIIP》 2.4 大节

小结

是否能够拜访取决于平安组配置

数据链路转发示意图

会通过calicao网卡，每个非hostnetwork的pod会和calicao网卡造成veth pair，用于和其余pod或node进行通信
整个链路不会和申请不会通过pod所调配的ENI，间接在OS 的ns中命中 Ip rule 被转发
出ECS后，依据要拜访的pod和该pod ENI所属vswitch，命中VPC路由规定或者间接VSW上的二层转发；
整个申请链路是

去方向：ECS1 Pod1 eth0 -> cali1xxx > ECS eth0 -> Pod1 member eni -> vpc route rule(如有) -> Pod2 member eni -> Trunk eni ( ECS2) cali2 xxx -> ECS2 Pod1 eth0

回方向：ECS2 Pod1 eth0 -> Trunk eni ( ECS2) cali2 xxx -> Pod2 member eni -> vpc route rule(如有) -> Pod1 member eni -> Trunk eni ( ECS1) -> cali1xxx -> ECS1 Pod1 eth0

通过ipvs规定fnat转化，数据包是以源pod IP 从ECS eth0 出，申请目标pod IP。（拜访SVC clusterIP，以及Local模式下拜访External IP）
这个通过的ENI有 ECS1 的eth0， Pod1 member eni，Pod2 member eni。所以这三个网卡的平安组的配置都会影响数据链路的连通性

2.7 场景七：集群内源端拜访SVC IP（源端和SVC后端不同节点，不同平安组，含Local模式拜访external IP）

环境

cn-hongkong.10.0.4.20 节点上存在客户端 centos-59cdc5c9c4-l5vf9 和IP 10.0.4.27cn-hongkong.10.0.4.244 节点上存在服务端 nginx-96bb9b7bb-wwrdm 和IP 10.0.5.35

nginx 的svc的ClusterIP是 192.168.31.83 External IP是 47.243.87.204

内核路由

小结

是否能够拜访取决于平安组配置

数据链路转发示意图

会通过calicao网卡，每个非hostnetwork的pod会和calicao网卡造成veth pair，用于和其余pod或node进行通信
整个链路不会和申请不会通过pod所调配的ENI，间接在OS 的ns中命中 Ip rule 被转发
出ECS后，依据要拜访的pod和该pod ENI所属vswitch，命中VPC路由规定或者间接VSW上的二层转发；
整个申请链路是

去方向：ECS1 Pod1 eth0 -> cali1xxx > ECS eth0 -> Pod1 member eni -> vpc route rule(如有) -> Pod2 member eni -> Trunk eni ( ECS2) cali2 xxx -> ECS2 Pod1 eth0

回方向：ECS2 Pod1 eth0 -> Trunk eni ( ECS2) cali2 xxx -> Pod2 member eni -> vpc route rule(如有) -> Pod1 member eni -> Trunk eni ( ECS1) -> cali1xxx -> ECS1 Pod1 eth0

通过ipvs规定fnat转化，数据包是以源pod IP 从ECS eth0 出，申请目标pod IP。（拜访SVC clusterIP，以及Local模式下拜访External IP）
这个通过的ENI有 ECS1 的eth0， Pod1 member eni，Pod2 member eni。所以这三个网卡的平安组的配置都会影响数据链路的连通性。须要保障平安组相互放通Pod和ECS的响应IP

2.8 场景八：Cluster模式下，集群内源端拜访SVC ExternalIP（源端和SVC后端不同节点，不同平安组）

环境

cn-hongkong.10.0.4.20 节点上存在客户端 centos-59cdc5c9c4-l5vf9 和IP 10.0.4.27cn-hongkong.10.0.4.244 节点上存在服务端 nginx-96bb9b7bb-wwrdm 和IP 10.0.5.35

nginx 的svc的ClusterIP是 192.168.31.83 External IP是 47.243.87.204, ExternalTrafficPolicy 是 Cluster模式

内核路由

ENI-Trunking相比拟ENIIP来说，只是在VPC侧减少了对应的Truning和Member ENI，在OS内并无区别，此处能够参考《全景分析阿里云容器网络数据链路（三）—— Terway ENIIP》 2.5 大节

小结

是否能够拜访取决于平安组配置

数据链路转发示意图

会通过calicao网卡，每个非hostnetwork的pod会和calicao网卡造成veth pair，用于和其余pod或node进行通信
整个链路不会和申请不会通过pod所调配的ENI，间接在OS 的ns中命中 Ip rule 被转发
出ECS后，依据要拜访的pod和该pod ENI所属vswitch，命中VPC路由规定或者间接VSW上的二层转发；
整个申请链路是ECS1 Pod1 eth0 -> cali1xxx > ECS eth0 -> vpc route rule(如有) -> Pod2 member eni -> Trunk eni ( ECS2) cali2 xxx -> ECS2 Pod1 eth0
通过ipvs规定fnat转化，数据包是以源pod IP 从ECS eth0 出，申请目标pod IP。（拜访SVC clusterIP，以及Local模式下拜访External IP）
这个通过的ENI有 ECS1 的eth0，Pod2 member eni。所以这两个网卡的平安组的配置都会影响数据链路的连通性。须要保障平安组相互放通Pod和ECS的响应IP

2.9 场景九：Cluster模式下，集群内源端拜访SVC ExternalIP（源端和SVC后端不同节点，雷同平安组）

环境

cn-hongkong.10.0.4.20 节点上存在客户端 centos-59cdc5c9c4-l5vf9 和IP 10.0.4.27cn-hongkong.10.0.4.22 节点上存在服务端 nginx-6f545cb57c-kt7r8 和IP 10.0.4.30

nginx 的svc的ClusterIP是 192.168.81.92 External IP是 8.210.162.178 ExternalTrafficPolicy为Cluster

内核路由

小结

是否能够拜访取决于平安组配置

数据链路转发示意图

会通过calicao网卡，每个非hostnetwork的pod会和calicao网卡造成veth pair，用于和其余pod或node进行通信
整个链路不会和申请不会通过pod所调配的ENI，间接在OS 的ns中命中 Ip rule 被转发
出ECS后，依据要拜访的pod和该pod ENI所属vswitch，命中VPC路由规定或者间接VSW上的二层转发；
整个申请链路是ECS1 Pod1 eth0 -> cali1xxx > ECS eth0 -> vpc route rule(如有) -> Pod2 member eni -> Trunk eni ( ECS2) cali2 xxx -> ECS2 Pod1 eth0
通过ipvs规定fnat转化，数据包是以源pod IP 从ECS eth0 出，申请目标pod IP。（拜访SVC clusterIP，以及Local模式下拜访External IP）
这个通过的ENI有 ECS1 的eth0，Pod2 member eni。所以这两个网卡的平安组的配置都会影响数据链路的连通性。须要保障平安组相互放通Pod和ECS的响应IP

2.10 场景十：集群外拜访SVC IP

环境

cn-hongkong.10.0.4.20 节点上存在客户端 centos-59cdc5c9c4-l5vf9 和IP 10.0.4.27cn-hongkong.10.0.4.22 节点上存在服务端 nginx-6f545cb57c-kt7r8 和IP 10.0.4.30

nginx 的svc的ClusterIP是 192.168.81.92 External IP是 8.210.162.178 ExternalTrafficPolicy为Cluster

SLB相干配置

在SLB控制台，能够看到 lb-j6cmv8aaojf7nqdai2a6a 虚构服务器组的后端服务器组是两个后端nginx pod 的的ENI eni-j6cgrqqrtvcwhhcyuc28, eni-j6c54tyfku5855euh3db 和 eni-j6cf7e4qnfx22mmvblj0，这几个ENI 都是member ENI

小结

是否能够拜访取决于平安组配置

数据链路转发示意图

会通过calicao网卡，每个非hostnetwork的pod会和calicao网卡造成veth pair，用于和其余pod或node进行通信
数据链路：client -> SLB -> Pod Member ENI + Pod Port -> Trunking ENI -> ECS1 Pod1 eth0
ExternalTrafficPolicy 为Local或Cluster模式下， SLB只会将 pod调配的member ENI挂在到SLB的虚构服务器组
SLB转发申请只会转发到指标member ENI上，而后通过vlan发送到Trunk ENI，再由Trunk ENI 转发到 POD

总结

本篇文章次要聚焦ACK 在Terway ENI-Trunking模式下，不同SOP场景下的数据链路转发门路。随同着客户对业务网络的更精细化的治理需要，引入了Pod维度交换机和平安组配置设置，在Terway ENI-Trunking模式下，一共能够分为10个SOP场景，并对这些场景技术实现原理，云产品配置等一一梳理并总结，这对咱们遇到Terway ENI-Trunking架构下的链路抖动、最优化配置，链路原理等提供了初步指引方向。在Terway ENI-Trunking模式下，利用veth pair来联通宿主机和pod的网络空间，pod的地址是来源于弹性网卡的辅助IP地址，并且节点上须要配置策略路由来保障辅助IP的流量通过它所属的弹性网卡，通过此种形式能够实现ENI多Pod共享，大大晋升了Pod的部署密度，同时利用tc egress/ingress 在数据流输出ECS时候，打上或者去除VLAN tag，以便实现数据流量能真正的走到属于他的Member ENI网卡，从而实现精细化的治理。目前微服务越来越流行，采纳sidecar的形式，让每个pod都能够成为一个网络节点，从而实现pod中不同的流量实现不同的网络行为和可观测性，下一系列咱们将进入到Terway ENIIP模式的全景解析最初一章——《全景分析阿里云容器网络数据链路（六）—— ASM Istio》。