弹性网卡中继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模式架构》群内非SVC后端pod所在节点访问SVC ClusterIP。通过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-l5vf9Pod匹配了相应的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 来实现的。
1) Terway ENI-Trunking 模式容器网络数据链路剖析
可以看到由于可以实现Pod维度的安全组,交换机设置,那么宏观上不同链路访问必然更加趋于复杂,我们可以将Terway ENI-TRunking模式下的网络链路大体分为以Pod IP对外提供服务和以SVC对外提供服务两个大的SOP场景,进一步细分,可以归纳为10个不同的小的SOP场景。
对这20个场景的数据链路梳理合并,这些场景可以归纳为下面10类典型的场景:
● 通节点访问Pod(相同or不同安全组);
● 同节点同安全组TrunkPod互访(含访问SVC IP,源端和svc后端部署在同一节点);
● 同节点不同安全组TrunkPod互访(含访问SVC IP,源端和svc后端部署在同一节点);
● 不同节点同安全组TrunkPod互访;
● 不同节点不同安全组TrunkPod互访;
● 集群内源端访问SVC IP(源端和SVC后端不同节点,相同安全组,含Local模式访问external IP);
● 集群内源端访问SVC IP(源端和SVC后端不同节点,不同安全组,含Local模式访问external IP);
● Cluster模式下,集群内源端访问SVC ExternalIP(源端和SVC后端不同节点,不同安全组);
● Cluster模式下,集群内源端访问SVC ExternalIP(源端和SVC后端不同节点,相同安全组);
● 集群外访问SVC IP;
2) 场景一:通节点访问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网卡在这里的主要作用是用于:
● 节点访问Pod;
● 当节点或者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可以访问nginxPod的80 端口。
置于数据面流量在OS层面的流量转发逻辑,这个类似于《Terway ENIIP模式架构》群内非SVC后端pod所在节点访问SVC ClusterIP,不在这里做过多的叙述。
小结
可以访问到目的端
数据链路转发示意图:
● 会经过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的安全组无关;
3) 场景二:同节点同安全组TrunkPod互访(含访问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网卡在这里的主要作用是用于:
● 节点访问Pod;
● 当节点或者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可以访问nginxPod的80 端口。
置于数据面流量在OS层面的流量转发逻辑,这个类似于《Terway ENIIP模式架构》群内非SVC后端pod所在节点访问SVC ClusterIP,不在这里做过多的叙述。
小结
可以访问到目的端
数据链路转发示意图:
● 会经过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时捕捉不到;
更多精彩内容,欢迎观看:
《云原生网络数据面可观测性最佳实践》——二、全景剖析阿里云容器网络数据链路——6. ASM Istio 模式架构设计(中):https://developer.aliyun.com/article/1221385?spm=a2c6h.13148508.setting.33.15f94f0eCydDfj