1. 前言
近几年，企业基础设施云原生化的趋势越来越强烈，从最开始的IaaS化到现在的微服务化，客户的颗粒度精细化和可观测性的需求更加强烈。容器网络为了满足客户更高性能和更高的密度，也一直在高速的发展和演进中，这必然对客户对云原生网络的可观测性带来了极高的门槛和挑战。为了提高云原生网络的可观测性，同时便于客户和前后线同学增加对业务链路的可读性，ACK产研和AES联合共建，合作开发ack net-exporter和云原生网络数据面可观测性系列，帮助客户和前后线同学了解云原生网络架构体系，简化对云原生网络的可观测性的门槛，优化客户运维和售后同学处理疑难问题的体验 ，提高云原生网络的链路的稳定性。
鸟瞰容器网络，整个容器网络可以分为三个部分：Pod网段，Service网段和Node网段。 这三个网络要实现互联互通和访问控制，那么实现的技术原理是什么？整个链路又是什么，限制又是什么呢？Flannel， Terway有啥区别？不同模式下网络性能如何？这些，需要客户在下搭建容器之前，就要依据自己的业务场景进行选择，而搭建完毕后，相关的架构又是无法转变，所以客户需要对每种架构特点要有充分了解。比如下图是个简图，Pod网络既要实现同一个ECS的Pod间的网络互通和控制，又要实现不同ECS Pod间的访问， Pod访问SVC 的后端可能在同一个ECS 也可能是其他ECS，这些在不同模式下，数据链转发模式是不同的，从业务侧表现结果也是不一样的。
本文是[全景剖析容器网络数据链路]第三部分，主要介绍Kubernetes Terway ENIIP模式下，数据面链路的转转发链路，一是通过了解不同场景下的数据面转发链路，从而探知客户在不同的场景下访问结果表现的原因，帮助客户进一步优化业务架构；另一方面，通过深入了解转发链路，从而在遇到容器网络抖动时候，客户运维以及阿里云同学可以知道在哪些链路点进行部署观测手动，从而进一步定界问题方向和原因。
系列一：全景剖析阿里云容器网络数据链路（一）—— Flannel
系列二：全景剖析阿里云容器网络数据链路（二）—— Terway ENI
系列三：全景剖析阿里云容器网络数据链路（三）—— Terway ENIIP
系列四：全景剖析阿里云容器网络数据链路（四）—— Terway IPVLAN+EBPF
系列五：全景剖析阿里云容器网络数据链路（五）—— Terway ENI-Trunking
系列六：全景剖析阿里云容器网络数据链路（六）—— ASM Istio
2. Terway ENIIP 模式架构设计
弹性网卡(ENI)支持配置多个辅助IP的功能，单个弹性网卡(ENI)根据实例规格可以分配6-20个辅助IP，ENI多IP模式就是利用了这个辅助IP分配给容器，从而大幅提高了Pod部署的规模和密度。在网络联通的方式上，Terway支持选择Veth pair策略路由和ipvlan l两种方案，Terway主要考虑了这些：1. 在节点上如何把弹性网卡(ENI)的辅助IP的流量都走对应的弹性网卡出去，并使用弹性网卡本身的mac地址而不被丢包 2.如何兼容容器服务目前广泛的Centos 7.x的3.10的版本的内核
Pod 所使用的CIDR网段和节点的CIDR是同一个网段
Pod 内部可以看到是有一张网卡的，一个是eth0，其中eth0 的IP就是 Pod的IP，此网卡的MAC地址和控制台上的ENI的MAC地址不一致，同时ECS上有多张ethx的网卡，说明ENI附属网卡并不是直接挂在到了Pod的网络命名空间
Pod内有只有指向eth0的默认路由，说明Pod访问任何地址段都是从eth0为统一的出入口
如上图所示，我们可以容器的网络命名空间中通过ip addr 看到一个eth0@if63的标志位，其中 ‘63' 这个将会协助我们在ECS的OS内找到和容器网络命名空间中的veth pair相对一个。在ECS OS 内我们通过ip addr | grep 63: 可以找到cali44ae9fbceeb 这个虚拟网卡，这个就是veth pair在ECS OS侧相对的那一个。
ECS OS内对于数据流量是怎么判断去哪个容器呢？ 通过OS Linux Routing 我们可以看到，所有目的是 Pod IP 的流量都会被转发到Pod对应的calico虚拟往卡上，到这里为止，ECS OS 和Pod的网络命名空间已经建立好完整的出入链路配置了。
在veth pair中实现了多个Pod共享一个ENI的方式来提升了ECS的Pod部署密度，那么如何知道Pod是被分配到哪个ENI呢？Terway Pod是通过daemonset的方式部署在每个节点上的，通过下面命令可以看到每个节点上的Terway Pod。通过terway-cli show factory 命令可以看到节点上的附属ENI数量、MAC地址以及每个ENI上的IP
故Terway ENIIP模式总体可以归纳为：
在网络联通的方式上，采用选择Veth pair策略路由
一对veth pair来联通宿主机和pod的网络空间，pod的地址是来源于弹性网卡的辅助IP地址，并且节点上需要配置策略路由来保证辅助IP的流量经过它所属的弹性网卡。
同主机上的容器通信直接通过主机上的路由到同一个主机上别的容器对应的veth上
不同主机的容器通信经过VPC的网络进行转发到对应的机器上，再通过机器上的路由转发到容器中
容器和其所在的宿主机之间的通信直接通过连接到宿主机namespace的veth pair和路由打通
容器到其他主机通过VPC的网络转发到对应的机器，其他主机到容器通过VPC网络转发到对应的弹性网卡，然后通过路由转发到容器的Veth上
容器到专线和共享服务也都是通过VPC的网络转发
容器到公网的访问经过VSwitch配置的SNAT网关直接将源IP转换成EIP的地址到外部网络
弹性网卡(ENI)支持配置多个辅助IP的功能，单个弹性网卡(ENI)根据实例规格可以分配6-20个辅助IP，ENI多IP模式就是利用了这个辅助IP分配给容器，从而大幅提高了Pod部署的规模和密度。
3. Terway ENIIP 模式容器网络数据链路剖析
针对容器网络特点，我们可以将Terway ENI模式下的网络链路大体分为以Pod IP对外提供服务和以SVC对外提供服务两个大的SOP场景，进一步细分，可以归纳为7个不同的小的SOP场景。
对这8个场景的数据链路梳理合并，这些场景可以归纳为下面8类典型的场景：
TerwayENI架构下，不同的数据链路访问情况下，可以总结归纳为为8类：
访问 Pod IP， 同节点访问Pod
访问Pod IP/SVC IP(Cluster or Local)，同节点pod间互访（pod属于同or不同ENI）
访问PodIP ，异节点pod间互访
集群内非SVC后端pod所在节点访问SVC ClusterIP
Cluster模式，集群内非SVC后端pod所在节点访问SVC External IP
Local模式，集群内非SVC后端pod所在节点访问SVC External IP
集群外访问SVC External IP
3.1 场景一：访问Pod IP，同节点访问pod
环境
cn-hongkong.10.0.1.82 节点上存在 nginx-7d6877d777-zp5jg 和 10.0.1.104
内核路由
nginx-7d6877d777-zp5jg IP地址 10.0.1.104 ，该容器在宿主机表现的PID是1094736，该容器网络命名空间有指向容器eth0的默认路由
该容器eth0在ECS OS 内对应veth pair是calif03b26f9a43
在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。
小结
可以访问到目的端
nginx-7d6877d777-zp5jg netns eth0 可以抓到数据包
nginx-7d6877d777-zp5jg calif03b26f9a43 可以抓到数据包
数据链路转发示意图：
会经过calicao网卡，每个非hostnetwork的pod会和calicao网卡形成veth pair，用于和其他pod或node进行通信
整个链路不会和请求不会经过pod所分配的ENI，直接在OS的ns中命中Ip rule 被转发
整个请求链路是 OS -> calixxxxx -> ECS Pod net eth0
整个链路会经过两次内核协议栈：ECS OS 和 Pod
数据链路要经过两次内核协议栈，是Pod1 协议栈、ECS1 协议栈
3.2 场景二：访问Pod IP/SVC IP(Cluster or Local)，同节点pod访问pod（pod属于同or不同ENI）
环境
cn-hongkong.10.0.1.82 节点上存在 nginx-7d6877d777-zp5jg 和 10.0.1.104
cn-hongkong.10.0.1.82 节点上存在 centos-67756b6dc8-h5wnp 和 10.0.1.91
Service 是 nginx ， ClusterIP是 192.168.2.115 ExternalIP是 10.0.3.62
内核路由
nginx-7d6877d777-zp5jg IP地址 10.0.1.104 ，该容器在宿主机表现的PID是1094736，该容器网络命名空间有指向容器eth0的默认路由
该容器eth0在ECS OS 内对应veth pair是calif03b26f9a43
用上述类似办法可以发现centos-67756b6dc8-h5wnp 的veth pair的 cali44ae9fbceeb，Pod网络空间只有默认路由。
在ECS OS内，有指向Pod IP，下一跳为为calixxxx的路由，通过前文可以知道calixxx网卡是和每个pod内的veth1组成的pair，所以，pod内访问SVC的CIDR会有指向veth1的路由，不会走默认的eth0路由。故：calixx网卡在这里的主要作用是用于：1. 节点访问Pod 2. 当节点或者Pod访问 SVC的CIDR时，会走ECS OS内核协议栈转换，走到calixxx和eth0访问pod。
说明相关的路由转发是在ECS OS层面进行的，Pod的calixx网卡起到了一个桥梁和连通的作用。
源端ECS上的的IPVS规则（如果访问的是SVC IP）
如果同节点上访问的是SVC 的IP（ClusterIP or ExternalIP）,在节点上我们查看SVC的相关IPVS转发规则：
Service 的ExternalTrafficPolicy是Local
SVC nginx CLusterIP是 192.168.2.115， ExternalIP是10.0.3.62， 后端是10.0.1.104 和10.0.3.58
cn-hongkong.10.0.1.82
对于SVC的ClusterIP，可以看到SVC的后端两个Pod都会被加到IPVS的转发规则
对于SVC的ExternalIP，可以看到SVC的后端，只有该节点的后端Pod 10.0.1.104才会被加到IPVS的转发规则
在LoadBalancer的SVC模式下，如果ExternalTrafficPolicy为Local，对于ClusterIP来说，会把所有SVC后端Pod都会加到该节点的IPVS转发规则；对于ExternalIP，只会把该节点上的SVC后端Pod才会加到IPVS规则中。如果该节点没有SVC后端Pod，则该节点上的Pod访问SVC的ExternalIP将会是失败。
Service的ExternalTrafficPolicy是Cluster
SVC nginx1 CLusterIP是 192.168.2.253， ExternalIP是10.0.3.63， 后端是10.0.1.104 和10.0.3.58
cn-hongkong.10.0.1.82
对于SVC的ClusterIP，可以看到SVC的后端两个Pod都会被加到IPVS的转发规则
对于SVC的ExternalIP，可以看到SVC的后端两个Pod都会被加到IPVS的转发规则
在LoadBalancer的SVC模式下，如果ExternalTrafficPolicy为Cluster，对于ClusterIP或ExternalIP来说，会把所有SVC后端Pod都会加到该节点的IPVS转发规则。
小结
可以访问到目的端
Conntrack表信息
Service nginx 的ExternalTrafficPolicy是Local
SVC nginx CLusterIP是 192.168.2.115， ExternalIP是10.0.3.62， 后端是10.0.1.104 和10.0.3.58
如果访问的是SVC的ClusterIP，通过conntrack 信息，可以看到src是源端Pod 10.0.1.91 ，dst是 SVC ClusterIP 192.168.2.115，dport是SVC中的port。并且期望是10.0.1.104 来回包给 10.0.1.91 。
如果访问的是SVC的ExternalIP，通过conntrack 信息，可以看到src是源端Pod 10.0.1.91 ，dst是 SVC ExternalIP 10.0.3.62 ，dport是SVC中的port。并且期望是10.0.1.104 来回包给 10.0.1.91 。
Service nginx1 的ExternalTrafficPolicy是Cluster
SVC nginx1 CLusterIP是 192.168.2.253， ExternalIP是10.0.3.63， 后端是10.0.1.104 和10.0.3.58
如果访问的是SVC的ClusterIP，通过conntrack 信息，可以看到src是源端Pod 10.0.1.91 ，dst是 SVC ClusterIP 192.168.2.253 ，dport是SVC中的port。并且期望是10.0.1.104 来回包给 10.0.1.91 。
如果访问的是SVC的ExternalIP，通过conntrack 信息，可以看到src是源端Pod 10.0.1.91 ，dst是 SVC ExternalIP 10.0.3.63 ，dport是SVC中的port。并且期望是节点ECS的IP 10.0.1.82 来回包给 10.0.1.91 。
综上可以看到src变换了多次，故在Cluster 模式下，会存在丢失真实客户端IP的情况
数据链路转发示意图：
会经过calicao网卡，每个非hostnetwork的pod会和calicao网卡形成veth pair，用于和其他pod或node进行通信
整个链路不会和请求不会经过pod所分配的ENI，直接在OS 的ns中命中 Ip rule 被转发
整个请求链路是ECS1 Pod1 eth0 -> Pod1 calixxxx -> Pod2 calixxxx -> ECS1 Pod2 eth0
访问SVC IP， SVC 会在源端pod eth0和calixxx网卡捕捉到，在目的端pod的eth0和calixxx时捕捉不到
在LoadBalancer的SVC模式下，如果ExternalTrafficPolicy为Local，对于ClusterIP来说，会把所有SVC后端Pod都会加到该节点的IPVS转发规则；对于ExternalIP，只会把该节点上的SVC后端Pod才会加到IPVS规则中。
在LoadBalancer的SVC模式下，如果ExternalTrafficPolicy为Cluster，对于ClusterIP或ExternalIP来说，会把所有SVC后端Pod都会加到该节点的IPVS转发规则，同时无法保留src地址。
数据链路要经过三次内核协议栈，是Pod1 协议栈、ECS1 协议栈、Pod2 协议栈
3.3 场景三：访问PodIP ，异节点pod间互访
环境
cn-hongkong.10.0.1.82 节点上存在 centos-67756b6dc8-h5wnp 和 10.0.1.91
cn-hongkong.10.0.3.49 节点上存在 nginx-7d6877d777-lwrfc 和 10.0.3.58
内核路由
centos-67756b6dc8-h5wnp IP地址 10.0.1.104 ，该容器在宿主机表现的PID是2211426，该容器网络命名空间有指向容器eth0的默认路由
用上述类似办法可以发现centos-67756b6dc8-h5wnp 的veth pair的 cali44ae9fbceeb，Pod网络空间只有默认路由。
在ECS OS内，有指向Pod IP，下一跳为为calixxxx的路由，通过前文可以知道calixxx网卡是和每个pod内的veth1组成的pair，所以，pod内访问SVC的CIDR会有指向veth1的路由，不会走默认的eth0路由。故：calixx网卡在这里的主要作用是用于：1. 节点访问Pod 2. 当节点或者Pod访问 SVC的CIDR时，会走ECS OS内核协议栈转换，走到calixxx和eth0访问pod,对于目的为外部地址，则走Pod所属的ENI 出ECS进入到了VPC。
小结
可以访问到目的端
数据链路转发示意图：
会经过calicao网卡，每个非hostnetwork的pod会和calicao网卡形成veth pair，用于和其他pod或node进行通信
整个链路请求会经过pod所分配的ENI，直接在OS的ns中命中Ip rule 被转发；
出ECS后，根据要访问的pod和该pod ENI所属vswitch，命中VPC路由规则或者直接VSW上的二层转发；
整个请求链路是ECS1 Pod1 eth0-> ECS1 Pod1 calixxxxx-> ECS1 ethx -> vpc route rule(如有) -> ECS2 ethx -> ECS2 Pod2 calixxxxx -> ECS2 Pod2 eth0
数据链路要经过四次内核协议栈，Pod1 协议栈、ECS1 协议栈、Pod2 协议栈、ECS2 协议栈
3.4 场景四：群内非SVC后端pod所在节点访问SVC ClusterIP
环境
cn-hongkong.10.0.3.49 节点上存在 nginx-7d6877d777-h4jtf 和 10.0.3.58
cn-hongkong.10.0.1.82 节点上存在 centos-67756b6dc8-h5wnp 和 10.0.1.91
Service1 是 nginx ， ClusterIP是 192.168.2.115 ExternalIP是 10.0.3.62
Service2 是 ngin1 ， ClusterIP是 192.168.2.253 ExternalIP是 10.0.3.63
内核路由
内核路由部分已经在2.2 和2.3 小结中详细说明，这里不再进行过多阐述
源端ECS上的的IPVS规则
根据2.2 小结中的源端ECS上的IPVS规则， 我们可以得到：无论在哪种SVC模式下，对于ClusterIP来说，会把所有SVC后端Pod都会加到该节点的IPVS转发规则
小结
可以访问到目的端
Conntrack表信息
Service nginx 的ExternalTrafficPolicy是Local
SVC nginx CLusterIP是 192.168.2.115， ExternalIP是10.0.3.62， 后端是10.0.1.104 和10.0.3.58
cn-hongkong.10.0.1.82
源端ECS上src是源端Pod 10.0.1.91 ，dst是 SVC ClusterIP 192.168.2.115，dport是SVC中的port。并且期望是10.0.3.58 来回包给 10.0.1.91 。
cn-hongkong.10.0.3.49
目的端ECS上src是源端Pod 10.0.1.91 ，dst是 pod 的IP 10.0.3.58，dport是pod的port。并且期望此pod 来回包给 10.0.1.91 。
Service nginx1 的ExternalTrafficPolicy是Cluster
SVC nginx1 CLusterIP是 192.168.2.253， ExternalIP是10.0.3.63， 后端是10.0.1.104 和10.0.3.58
cn-hongkong.10.0.1.82
源端ECS上src是源端Pod 10.0.1.91 ，dst是 SVC ClusterIP 192.168.2.115，dport是SVC中的port。并且期望是10.0.3.58 来回包给 10.0.1.91 。
cn-hongkong.10.0.3.49
目的端ECS上src是源端Pod 10.0.1.91 ，dst是 pod 的IP 10.0.3.58，dport是pod的port。并且期望此pod 来回包给 10.0.1.91 。
对于ClusterIP来说，源端ECS会把所有SVC后端Pod都会加到该节点的IPVS转发规则，目的端ECS是捕获不到任何SVC ClusterIP信息的，只能捕获到源端Pod的IP，所以回包的时候会回到源端Pod的附属网卡上。
数据链路转发示意图：
会经过calicao网卡，每个非hostnetwork的pod会和calicao网卡形成veth pair，用于和其他pod或node进行通信
整个链路请求会经过pod所分配的ENI，直接在OS 的ns中命中 Ip rule 被转发；
出ECS后，根据要访问的pod和该pod ENI所属vswitch，命中VPC路由规则或者直接VSW上的二层转发；
整个请求链路是
去方向：
ECS1 Pod1 eth0 -> ECS1 Pod1 calixxxxxx -> ECS1 主网卡 eth0 -> vpc route rule(如有) -> ECS2 附属网卡ethx -> ECS2 Pod2 calixxxxx -> ECS2 Pod2 eth0
回方向：
ECS2 Pod2 eth0 -> ECS2 Pod2 calixxxxx -> ECS2 附属网卡ethx -> vpc route rule(如有) -> ECS1 附属网卡 eth1 -> ECS1 Pod1 calixxxxxx -> ECS1 Pod1 eth0
对于ClusterIP来说，源端ECS会把所有SVC后端Pod都会加到该节点的IPVS转发规则，目的端ECS是捕获不到任何SVC ClusterIP信息的，只能捕获到源端Pod的IP，所以回包的时候会回到源端Pod的附属网卡上。
数据链路要经过四次内核协议栈，Pod1 协议栈、ECS1 协议栈、Pod2 协议栈、ECS2 协议栈
3.5 场景五：Cluster模式，集群内非SVC后端pod所在节点访问SVC External IP
环境
cn-hongkong.10.0.3.49 节点上存在 nginx-7d6877d777-h4jtf 和 10.0.3.58
cn-hongkong.10.0.1.82 节点上存在 centos-67756b6dc8-h5wnp 和 10.0.1.91
Service2 是 ngin1 ， ClusterIP是 192.168.2.253 ExternalIP是 10.0.3.63
内核路由
内核路由部分已经在2.2 和2.3 小结中详细说明，这里不再进行过多阐述
源端ECS上的的IPVS规则
根据2.2 小结中的源端ECS上的IPVS规则， 我们可以得到：ExternalTrafficPolicy为Cluster模式下，对于ExternalIP来说，会把所有SVC后端Pod都会加到该节点的IPVS转发规则
小结
可以访问到目的端
Conntrack表信息
Service nginx1 的ExternalTrafficPolicy是Cluster
SVC nginx1 CLusterIP是 192.168.2.253， ExternalIP是10.0.3.63， 后端是10.0.1.104 和10.0.3.58
cn-hongkong.10.0.1.82
源端ECS上src是源端Pod 10.0.1.91 ，dst是 SVC ExternalIP 10.0.3.63，dport是SVC中的port。并且期望是10.0.3.58 来回包给源端ECS的地址10.0.1.82。
cn-hongkong.10.0.3.49
目的端ECS上src是源端Pod所在的ECS地址10.0.1.82 ，dst是 pod 的IP 10.0.3.58，dport是pod的port。并且期望此pod 来回包给源端ECS的地址10.0.1.82。
在ExternalTrafficPolicy为Cluster下，对于ExternalIP来说，源端ECS会把所有SVC后端Pod都会加到该节点的IPVS转发规则，目的端ECS是捕获不到任何SVC ExternalIP信息的，只能捕获到源端Pod所在的ECS的IP，所以回包的时候会回到源端Pod所在的ECS的主网卡上，这一点明显和2.4 小结中访问CusterIP有很明显区别 。
数据链路转发示意图：
会经过calicao网卡，每个非hostnetwork的pod会和calicao网卡形成veth pair，用于和其他pod或node进行通信
整个链路请求会经过pod所分配的ENI，直接在OS的ns中命中Ip rule 被转发；
出ECS后，根据要访问的pod和该pod ENI所属vswitch，命中VPC路由规则或者直接VSW上的二层转发；
整个请求链路是 ECS1 Pod1 eth0 -> ECS1 Pod1 calixxxx -> ECS1 主网卡ENI eth0 -> vpc route rule(如有) -> ECS2 附属网卡ethx -> ECS2 Pod2 calixxx -> ECS2 Pod2 eth0
在ExternalTrafficPolicy为Cluster下，对于ExternalIP来说，源端ECS会把所有SVC后端Pod都会加到该节点的IPVS转发规则，目的端ECS是捕获不到任何SVC ExternalIP信息的，只能捕获到源端Pod所在的ECS的IP，所以回包的时候会回到源端Pod所在的ECS的主网卡 。
数据链路要经过四次内核协议栈，Pod1 协议栈、ECS1 协议栈、Pod2 协议栈、ECS2 协议栈
3.6 场景六：Local模式，集群内非SVC后端pod所在节点访问SVC External IP
环境
cn-hongkong.10.0.3.49 节点上存在 nginx-7d6877d777-h4jtf 和 10.0.3.58
cn-hongkong.10.0.1.82 节点上存在 centos-67756b6dc8-h5wnp 和 10.0.1.91
Service1 是 nginx ， ClusterIP是 192.168.2.115 ExternalIP是 10.0.3.62
内核路由
内核路由部分已经在2.2 和2.3 小结中详细说明，这里不再进行过多阐述
源端ECS上的的IPVS规则
Service 的ExternalTrafficPolicy是Local
SVC nginx CLusterIP是 192.168.2.115， ExternalIP是10.0.3.62， 后端是10.0.1.104 和10.0.3.58
cn-hongkong.10.0.1.82
对于SVC的ExternalIP，可以看到SVC的后端，无任何转发规则
根据2.2 小结中的源端ECS上的IPVS规则， 我们可以得到：ExternalTrafficPolicy为Local模式下，对于ExternalIP来说，只会把本节点上的SVC的后端Pod加到节点上的IPVS转发规则，如果该节点没有SVC后端，则不会有任何可以转发的规则。
小结
不可以访问到目的端
Conntrack表信息
Service 的ExternalTrafficPolicy是Local
SVC nginx1 CLusterIP是 192.168.2.253， ExternalIP是10.0.3.63， 后端是10.0.1.104 和10.0.3.58
cn-hongkong.10.0.1.82 无任何conntrack记录表生成
数据链路转发示意图：
会经过calicao网卡，每个非hostnetwork的pod会和calicao网卡形成veth pair，用于和其他pod或node进行通信
整个链路请求不会经过pod所分配的ENI，直接在OS的ns中命中Ip rule 被转发；
整个请求链路是 ECS1 Pod1 eth0 -> ECS1 Pod1 calixxxx -> ECS host 空间ipvs/iptables规则，无后端转发ep终止链路。
ExternalTrafficPolicy为Local模式下，对于ExternalIP来说，只会把本节点上的SVC的后端Pod加到节点上的IPVS转发规则，如果该节点没有SVC后端，则不会有任何可以转发的规则。
3.7 场景七：集群外访问SVC External IP
环境
cn-hongkong.10.0.3.49 节点上存在 nginx-7d6877d777-h4jtf 和 10.0.3.58
cn-hongkong.10.0.1.47 节点上存在 nginx-7d6877d777-kxwdb 和 10.0.1.29
Service1 是 nginx ， ClusterIP是 192.168.2.115 ExternalIP是 10.0.3.62
SLB相关配置
在SLB控制台，可以看到 lb-j6cw3daxxukxln8xccive虚拟服务器组的后端服务器组是两个后端nginx pod 的的ENI eni-j6c4qxbpnkg5o7uog5kr 和 eni-j6c6r7m3849fodxdf5l7
从集群外部角度看，SLB的后端虚拟服务器组是SVC的后端Pod所属的两个ENI网卡，内网的IP 地址就是Pod的地址
小结
可以访问到目的端
数据链路转发示意图：
数据链路：client -> SLB -> Pod ENI + Pod Port -> ECS1 Pod1 eth0
数据链路要经过二次内核协议栈，Pod1 协议栈和ECS 协议栈
4. 总结
本篇文章主要聚焦ACK 在Terway ENIIP模式下，不同SOP场景下的数据链路转发路径。伴随着客户对性能的极致追求的需求，在Terway ENIIP模式下，一共可以分为7个SOP场景，并对这七个场景的转发链路，技术实现原理，云产品配置等一一梳理并总结，这对我们遇到Terway ENIIP架构下的链路抖动、最优化配置，链路原理等提供了初步指引方向。在Terway ENIIP 模式下，利用veth pair来联通宿主机和pod的网络空间，pod的地址是来源于弹性网卡的辅助IP地址，并且节点上需要配置策略路由来保证辅助IP的流量经过它所属的弹性网卡，通过此种方式可以实现ENI多Pod共享，大大提升了Pod的部署密度，但是veth pair必然会利用ECS的内核协议栈进行转发，此架构下性能必然不如ENI模式，ACK产研为了提升性能，结合内核的ebpf和ipvlan技术，开发了Terway ebpf + ipvlan 架构。 下一系列我们将进入到Terway ENIIP模式的全景解析——《全景剖析阿里云容器网络数据链路（四）—— Terway IPVLAN+EBPF》。
本系列联合作者 容器服务 @谢石