全景剖析阿里云容器网络数据链路（五）：Terway ENI-Trunking

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

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

鸟瞰容器网络，整个容器网络可以分为三个部分：Pod 网段，Service 网段和 Node 网段。这三个网络要实现互联互通和访问控制，那么实现的技术原理是什么？整个链路又是什么，限制又是什么呢？Flannel， Terway 有啥区别？不同模式下网络性能如何？这些，需要客户在下搭建容器之前，就要依据自己的业务场景进行选择，而搭建完毕后，相关的架构又是无法转变，所以客户需要对每种架构特点要有充分了解。比如下图是个简图，Pod 网络既要实现同一个 ECS 的 Pod 间的网络互通和控制，又要实现不同 ECS Pod 间的访问， Pod 访问 SVC 的后端可能在同一个 ECS 也可能是其他 ECS，这些在不同模式下，数据链转发模式是不同的，从业务侧表现结果也是不一样的。

1.png

本文是[全景剖析容器网络数据链路]第五部分部分，主要介绍 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 能力，带来更为细化的网络配置能力，提供极具竞争力的容器网络解决方案。

2.png

在 trunking 的命名空间内可以看到相关的 pod 信息和节点信息，其中 pod 应用的 IP 的网络我们稍后会详细说明

3.png

4.png

5.png

Pod 内有只有指向 eth0 的默认路由，说明 Pod 访问任何地址段都是从 eth0 为统一的出入口

6.png

那么 Pod 是如何 ECS OS 进行通信呢？在 OS 层面，我们一看到 calicxxxx 的网卡，可以看到是附属于 eth1 的，对于节点和 Pod 的通信连接，这个类似于《全景剖析阿里云容器网络数据链路（三）—— Terway ENIIP》 ，此处不再进行过多说明。通过 OS Linux Routing 我们可以看到，所有目的是 Pod IP 的流量都会被转发到 Pod 对应的 calico 虚拟往卡上，到这里为止，ECS OS 和 Pod 的网络命名空间已经建立好完整的出入链路配置了。

7.png

8.png

让我们把目光聚焦 ENI Trunking 本身。ENI Truning 是如何实现 Pod 的交换机和安全组的配置呢？Terway 增加一种名为 PodNetworking 的自定义资源来描述网络配置。您可以创建多个 PodNetworking，来规划不同网络平面。创建 PodNetworking 资源后，Terway 将同步网络配置信息，只有 status 成为 Ready 后，该网络资源才能对 Pod 生效。如下图所示，类型为 Elastic，只要 namespce 的标签的符合 tryunking：zoneb， 就给 pod 使用指定的安全组和交换机。

9.png

创建 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 维度的交换机，安全组的配置和管理。

10.png

通过 ECS 的控制台，我们也可以清楚的看到 memenber ENI 和 Trunking ENI 之间的关系，相应的安全组交换机等等信息。

11.png

12.png

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

13.png

故 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 场景。

14.png

对这 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 不同安全组）

环境

15.png

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

内核路由

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

16.png

17.png

该容器 eth0 在 ECS OS 内是通过 ipvlan 隧道的方式和 ECS 的附属 ENI eth1 建立的隧道，同时附属 ENI eth1 还有个虚拟的 calxxx 网卡

18.png

19.png

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

20.png

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

21.png

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

22.png

ENI 的网卡所属的安全组可以看到只允许了指定的 IP 可以访问 nginx pod 的 80 端口。

23.png

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

小结

可以访问到目的端

24.png

数据链路转发示意图

• 会经过 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 后端部署在同一节点）

环境

25.png

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 的默认路由

26.png

27.png

该容器 eth0 在 ECS OS 内是通过 ipvlan 隧道的方式和 ECS 的附属 ENI eth1 建立的隧道，同时附属 ENI eth1 还有个虚拟的 calixxxx  网卡

28.png

29.png

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

30.png

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

31.png

32.png

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

33.png

ENI 的网卡所属的安全组可以看到只允许了指定的 IP 可以访问 nginx pod 的 80 端口。

34.png

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

小结

可以访问到目的端

35.png

数据链路转发示意图

• 会经过 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 后端部署在同一节点）

环境

36.png

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 等.

37.png

通过安全组 sg-j6ccrxxxx 可以看到 centos 的 pod 可以访问外部所有的地址

38.png

同理，可以查看出服务端 Pod 的 nginx-96bb9b7bb-wwrdm 的安全组 sg-j6ccrze8utxxxxx 是只允许 192.168.0.0/16 可以访问

39.png

40.png

小结

可以访问到目的端

41.png

数据链路转发示意图

• 会经过 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 互访

环境

42.png

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。

43.png

44.png

小结

是否可以访问取决于安全组配置

45.png

数据链路转发示意图

• 会经过 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 互访

环境

46.png

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 可以访问外部所有的地址

47.png

48.png

同理，可以查看出服务端 Pod 的 nginx-96bb9b7bb-wwrdm 的安全组 sg-j6ccrze8utxxxxx 是只允许 192.168.0.0/16 可以访问

49.png

50.png

小结

是否可以访问取决于安全组配置

51.png

数据链路转发示意图

• 会经过 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）

环境

52.png

53.png

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 小节

小结

是否可以访问取决于安全组配置

54.png

数据链路转发示意图

• 会经过 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）

环境

55.png

56.png

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

内核路由

ENI-Trunking 相比较 ENIIP 来说，只是在 VPC 侧增加了对应的 Truning 和 Member ENI，在 OS 内并无区别，此处可以参考《全景剖析阿里云容器网络数据链路（三）—— Terway ENIIP》 2.4 小节

小结

是否可以访问取决于安全组配置

57.png

数据链路转发示意图

• 会经过 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 后端不同节点，不同安全组）

环境

58.png

59.png

60.png

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 小节

小结

是否可以访问取决于安全组配置

61.png

数据链路转发示意图

• 会经过 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 后端不同节点，相同安全组）

环境

62.png

63.png

64.png

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

内核路由

ENI-Trunking 相比较 ENIIP 来说，只是在 VPC 侧增加了对应的 Truning 和 Member ENI，在 OS 内并无区别，此处可以参考《全景剖析阿里云容器网络数据链路（三）—— Terway ENIIP》 2.5 小节

小结

是否可以访问取决于安全组配置

65.png

数据链路转发示意图

• 会经过 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

环境

66.png

67.png

68.png

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

69.png

70.png

小结

是否可以访问取决于安全组配置

71.png

数据链路转发示意图

• 会经过 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》。