乐趣区

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

jiezi

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

近几年，企业基础设施云原生化的趋势越来越强烈，从最开始的 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  网卡

在 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 命名空间下的 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

内核路由

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。所以这三个网卡的平安组的配置都会影响数据链路的连通性。须要保障 平安组相互放通 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

内核路由

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.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》。

退出移动版