弹性网卡(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策略路由较好。
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模式架构》原理，TerwayPod是通过daemonset的方式部署在每个节点上的，通过下面命令可以看到每个节点上的TerwayPod。通过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的数据包进行修改。
例如，同上图，可以看到集群内有一个名为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都无法被捕获到。
1) Terway IPVLAN+EBPF 模式容器网络数据链路剖析
针对容器网络特点，我们可以将Terway IPVLAN+EBPF模式下的网络链路大体分为以Pod IP对外提供服务和以SVC对外提供服务两个大的SOP场景，进一步细分，可以归纳为12个不同的小的SOP场景。
对这15个场景的数据链路梳理合并，这些场景可以归纳为下面11类典型的场景：
TerwayENI架构下，不同的数据链路访问情况下，可以总结归纳为11类：
● 访问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) 场景一：访问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；
3) 场景二：访问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。
通过此节点的terwayPod，我们可以利用 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网卡设备的两次转发，性能是更好的；
4) 场景三：访问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。
通过此节点的terwayPod，我们可以利用 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；
更多精彩内容，欢迎观看：
《云原生网络数据面可观测性最佳实践》——二、全景剖析阿里云容器网络数据链路——4. Terway IPVLAN+EBPF 模式架构设计（中）：https://developer.aliyun.com/article/1221414?spm=a2c6h.13148508.setting.30.15f94f0euQBp6L
