全景剖析阿里云容器网络数据链路(一)—— Flannel

简介: 本文是[全景剖析容器网络数据链路]第一部分,主要介绍Kubernetes Flannel模式下,数据面链路的转转发链路

1. 前言

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

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

image

本文是[全景剖析容器网络数据链路]第一部分,主要介绍Kubernetes Flannel模式下,数据面链路的转转发链路,一是通过了解不同场景下的数据面转发链路,从而探知客户在不同的场景下访问结果表现的原因,帮助客户进一步优化业务架构;另一方面,通过深入了解转发链路,从而在遇到容器网络抖动时候,客户运维以及阿里云同学可以知道在哪些链路点进行部署观测手动,从而进一步定界问题方向和原因。

系列一:全景剖析阿里云容器网络数据链路(一)—— Flannel

系列二:全景剖析阿里云容器网络数据链路(二)—— Terway ENI

系列三:全景剖析阿里云容器网络数据链路(三)—— Terway ENIIP

系列四:全景剖析阿里云容器网络数据链路(四)—— Terway IPVLAN+EBPF

系列五:全景剖析阿里云容器网络数据链路(五)—— Terway ENI-Trunking

系列六:全景剖析阿里云容器网络数据链路(六)—— ASM Istio

2. Flannel 模式架构设计

Flannel 模式下,ECS只有一个主网卡ENI,无其他附属网卡,ECS和节点上的Pod与外部通信都需要通过主网卡进行。 ACK Flannel会在每个节点创建cni0虚拟网卡作为Pod网络和ECS的主网卡eth0之间的桥梁。

image  image

集群的每个节点会起一个flannel agent,并且会给每个节点预分配一个Pod CIDR,这个Pod CIDR是ACK集群的Pod CIDR的子集。

image

容器的网络命名空间内会有一个eth0的虚拟网卡,同时存在下一跳指向该网卡的路由,该网卡会作为容器和宿主内核进行数据交换的出入口。容器和宿主机之间的数据链路是通过veth pair进行交换的,现在我们已经找到veth pair其中一个,如何去找另一个veth呢?

image  image

如上图所示,我们可以容器的网络命名空间中通过ip addr 看到一个eth0@if81 的标志位,其中 ‘81' 这个将会协助我们在ECS的OS内找到和容器网络命名空间中的veth pair相对一个。在ECS OS 内我们通过ip addr | grep 81: 可以找到vethd7e7c6fd 这个虚拟网卡,这个就是veth pair在ECS OS侧相对的那一个。

image

到目前为止容器内和OS 数据链路已经建立链接了,那么ECS OS内对于数据流量是怎么判断去哪个容器呢? 通过OS Linux Routing 我们可以看到,所有目的是 Pod CIDR 网段的流量都会被转发到cni0这张虚拟网卡,那么cni0是通过bridge方式将不同目的的数据链路指向到不同的vethxxx。到这里为止,ECS OS 和Pod的网络命名空间已经建立好完整的出入链路配置了。

image

3. Flannel 模式容器网络数据链路剖析

针对容器网络特点,我们可以将Flannel模式下的网络链路大体分为以Pod IP对外提供服务和以SVC对外提供服务两个大的SOP场景,进一步细分可以拆分到10个不同的小的SOP场景。image

对这10个场景的数据链路梳理合并,这些场景可以归纳为下面5类典型的场景:

  • Client和服务端Pod部署于同一个ECS

  • Client和服务端Pod部署于不同ECS

  • 访问SVC External IP, ExternalTrafficPolicy 为Cluster时,Client和服务端Pod部署于不同ECS,其中client为集群外

  • 访问SVC External IP, ExternalTrafficPolicy 为Local时, Client和服务端Pod部署于不同ECS,其中client为集群内

  • 访问SVC External IP, ExternalTrafficPolicy 为Local时, Client和服务端Pod部署于不同ECS,其中client为集群外

3.1 场景一:Client和服务端Pod部署于同一个ECS

此场景包含下面几个子场景,数据链路可以归纳为一种:

  1. 以Pod IP对外提供服务,Client和Pod部署于同一个节点;

  2. 以SVC ClusterIP对外提供服务,Client和SVC 后端Pod部署于同一节点;

  3. 以SVC ExternalIP对外提供服务,ExternalTrafficPolicy为Cluster/Local情况下,Client和SVC后端Pod部署于同一节点

环境

image

ap-southeast-1.10.0.0.180 节点上存在两个pod:centos-67756b6dc8-rmmxt IP地址172.23.96.23 和 nginx-7d6877d777-6jkfg 和172.23.96.24

内核路由

centos-67756b6dc8-rmmxt IP地址172.23.96.23,该容器在宿主机表现的PID是503478,该容器网络命名空间有指向容器eth0的默认路由

image  image

该容器eth0在ECS OS 内对应veth pair是vethd7e7c6fd

image  image

通过上述类似的办法,可以找到nginx-7d6877d777-6jkfg IP地址172.23.96.24,该容器在宿主机表现的PID是2981608,该容器eth0在ECS OS 内对应veth pair是vethd3fc7ff4

image

在ECS OS内,有指向Pod CIDR,下一跳为cni0的路由,以及cni0中有两个容器的vethxxx 网桥信息

image  image

小结

可以访问到目的端

数据链路转发示意图:

image

内核协议栈示意图:

image

  • 数据链路:ECS1 Pod1 eth0 -> vethxxx1 -> cni0 -> vethxxxx2 -> ECS1 Pod2 eth0

  • 数据链路要经过三次内核协议栈,分别是Pod1 协议栈, ECS OS协议栈 和 Pod2 协议栈

3.2 场景二:Client和服务端Pod部署于不同ECS

此场景包含下面几个子场景,数据链路可以归纳为一种:

  1. 以Pod IP对外提供服务,Client和Pod部署于不同节点;

  2. 以SVC ClusterIP对外提供服务,Client和SVC 后端Pod部署于不同节点;

  3. 以SVC ExternalIP对外提供服务,ExternalTrafficPolicy为Cluster情况下,集群内Client和SVC后端Pod部署于不同节点;

环境

image

ap-southeast-1.10.0.0.180 节点上存在两个pod:centos-67756b6dc8-rmmxt IP地址172.23.96.23 和 nginx1-76c99b49df-7plsr IP 地址172.23.96.163

Service nginx1 的ExternalTrafficPlicy 为 Cluster

image

内核路由

Pod 网络空间和ECS OS 网络空间的数据交换在 2.1 场景一中已经做了详细描述,此处不再果断篇幅描述。

源端Pod所在ECS的IPVS规则

可以看到,源端数据链路访问svc 的clusterip 192.168.13.23 时,如果链路到达ECS的OS内,会命中ipvs规则,被解析到svc的后端endpoint之一(本实例中只有一个pod,所以endpoint只有一个)

image

小结

可以成功访问到目的端

数据链路转发示意图:

image

VPC 路由表会自动配置目的地址是pod CIDR, 下一跳为 POD 网段所归属的ECS的自定义路由条目,该规则由ACK管控测通过openapi 调用VPC去配置,无需手动配置和删除

image

内核协议栈示意图:

image

Conntack 表信息(访问SVC 情况)

Node1:

src是源pod IP,dst是svc的ClusterIP,并且期望是由svc的其中一个endpoint 172.23.96.163 来回消息给源端pod

image

Node2:

目的pod所在ECS上conntrack 表记录是由源端pod访问目的pod,不会记录svc的clusterip地址

image

  • 数据链路:ECS1 Pod1 eth0 -> vethxxx1 -> cni0 -> ECS 1 eth0 -> VPC -> ECS2 eth0 -> cni0 -> vethxxxx2 -> ECS2 Pod2 eth0

  • 数据链路要经过四次内核协议栈,分别是Pod1 协议栈, ECS1 OS协议栈 , ECS2 OS协议栈和Pod2 协议栈

  • VPC 路由表会自动配置目的地址是pod CIDR, 下一跳为 POD 网段所归属的ECS的自定义路由条目,该规则由ACK管控测通过openapi 调用VPC去配置,无需手动配置和删除

  • 如果访问的SVC的cluster IP,或者是Cluster模式下,访问SVC的externalIP,数据链路通过veth pair进到ECS OS内后,会命中相应的IPVS规则,并根据负载规则,选择IPVS的某一个后端,进而打到其中的一个SVC 的后端endpoint,SVC的IP 只会再 PoD的eth0 , veth pair vethxxx被捕捉到,其他链路环节不会捕捉到svc的IP

3.3 场景三:ExternalTrafficPolicy为Local时,Client和服务端Pod部署于集群内不同ECS

此场景包含下面几个子场景,数据链路可以归纳为一种:

以SVC ExternalIP对外提供服务,ExternalTrafficPolicy为Local情况下,集群内Client和SVC后端Pod部署于不同节点;

环境

image

ap-southeast-1.10.0.0.180 节点上存在两个pod:centos-67756b6dc8-rmmxt IP地址172.23.96.23 和 nginx1-76c99b49df-7plsr IP 地址172.23.96.163

Service nginx1 ExternalTrafficPolicy 为 Local

image

内核路由

Pod 网络空间和ECS OS 网络空间的数据交换在 2.1 场景一中已经做了详细描述,此处不再果断篇幅描述。

源端Pod所在ECS的IPVS规则

可以看到,源端数据链路访问svc 的externalip 8.219.164.113 时,如果链路到达ECS的OS内,会命中ipvs规则,但是我们可以看到EcternalIP 并没有相关的后端endpoint,链路达到OS后,会命中IPVS规则,但是没有后端pod,所以会出现connection refused

image

小结

不可以访问到目的端,此时会访问失败,Connection refused

数据链路转发示意图:

image

内核协议栈示意图:

image

  • 数据链路:ECS1 Pod1 eth0 -> vethxxx1 ->

  • 数据链路要经过一次半内核协议栈,分别是Pod1 协议栈,半个 ECS1 OS协议栈

  • 如果访问的SVC的External IP,或者是Local模式下,访问SVC的externalIP,数据链路通过veth pair进到ECS OS内后,会命中相应的IPVS规则,但是由于Local模式,External IP的IPVS为空,所以命中规则但是无转发后端,整个链路会在ipvs终止,访问失败。所以建议集群内采用clusterip访问,这也是k8s官方推荐的最佳实践。

3.4 场景四:ExternalTrafficPolicy为Local时,Client来自于集群外

此场景包含下面几个子场景,数据链路可以归纳为一种:

A.访问SVC External IP, ExternalTrafficPolicy 为Local时, Client和服务端Pod部署于不同ECS,其中client为集群外

环境

image

Deployment为nginx1, 分别为三个pod nginx1-76c99b49df-4zsdj和nginx1-76c99b49df-7plsr 部署在 ap-southeast-1.10.0.1.206 ECS上,最后一个pod nginx1-76c99b49df-s6z79 部署在其他节点ap-southeast-1.10.0.1.216 上

Service nginx1 的ExternalTrafficPlicy 为 Local

image

内核路由

Pod 网络空间和ECS OS 网络空间的数据交换在 2.1 场景一中已经做了详细描述,此处不再果断篇幅描述。

SLB相关配置

从SLB控制台,可以看到SLB后端的虚拟服务器组中只有两个ECS节点ap-southeast-1.10.0.1.216 和 ap-southeast-1.10.0.1.206。集群内的其他节点 ,比如 ap-southeast-1.10.0.0.180 并未被加到SLB的后端虚拟服务器组中。 虚拟服务器组的IP 为 ECS的IP,端口为service里面的nodeport端口32580.

image

故ExternalTrafficPolicy为Local模式下,只有有Service后端pod所在的ECS节点才会被加入到SLB的后端虚拟服务器组中,参与SLB的流量转发,集群内的其他节点不参与SLB的转发

SLB虚拟服务器组ECS的IPVS规则

从SLB的虚拟服务器组中的两个ECS可以看到,对于nodeip+nodeport的 ipvs转发规则是不同。ExternalTrafficPolicy为Local模式下,只有该节点上的护短pod才会被加到该节点的ipvs转发规则中,其他节点上的后端pod不会加进来,这样保证了被SLB转发的链路,只会被转到该节点上的pod,不会转发到其他节点上。

node1: ap-southeast-1.10.0.1.206

image

node1: ap-southeast-1.10.0.1.216

image

小结

可以访问到目的端

数据链路转发示意图:

image

该图示意了只有后端pod所在ECS才会加到SLB后端中,从集群外部访问SVC的externalIP(SLB IP)的情况,可见数据链路只会被转发到虚拟服务器组中的ECS,不会再被转发到集群内其他节点上。

内核协议栈示意图:

image

Conntack 表信息

Node:

src是集群外部客户端IP,dst是节点IP,dport是SVC中的nodeport。并且期望是由该ECS上的pod 172.23.96.82 来回包给源端

image

  • 数据链路:client -> SLB -> ECS eth0 + ECS nodeport -> cni0 -> vethxxxxx -> ECS1 Pod1 eth0

  • 数据链路要经过两次内核协议栈,分别是Pod1 协议栈, ECS1 OS协议栈

  • ExternalTrafficPolicy为Local模式下,只有有Service后端pod所在的ECS节点才会被加入到SLB的后端虚拟服务器组中,参与SLB的流量转发,集群内的其他节点不参与SLB的转发

3.5 场景五:ExternalTrafficPolicy为Cluster时,Client来自于集群外

此场景包含下面几个子场景,数据链路可以归纳为一种:

访问SVCExternal IP, ExternalTrafficPolicy 为Cluster时, Client和服务端Pod部署于不同ECS,其中client为集群外

环境

image

Deployment为nginx1, 分别为三个pod nginx1-76c99b49df-4zsdj和nginx1-76c99b49df-7plsr 部署在 ap-southeast-1.10.0.1.206 ECS上,最后一个pod nginx1-76c99b49df-s6z79 部署在其他节点ap-southeast-1.10.0.1.216 上

Service nginx2 的ExternalTrafficPlicy 为 Cluster

image

内核路由

Pod 网络空间和ECS OS 网络空间的数据交换在 2.1 场景一中已经做了详细描述,此处不再果断篇幅描述。

SLB相关配置

从SLB控制台,集群内所有节点ap-southeast-1.10.0.0.180、ap-southeast-1.10.0.1.216 和 ap-southeast-1.10.0.1.206都被加到SLB的虚拟服务器组中。其中 虚拟服务器组的IP 为 ECS的IP,端口为service里面的nodeport端口30875.

image

故ExternalTrafficPolicy为CLuster模式下,集群内所有的ECS节点都会被加入到SLB的后端虚拟服务器组中,参与SLB的流量转发。

SLB虚拟服务器组ECS的IPVS规则

从SLB的虚拟服务器组中的可以看到,对于nodeip+nodeport的 ipvs转发规则是一致的。ExternalTrafficPolicy为CLuster模式下,所有的service后端pod都会被加到所有节点的ipvs的转发规则中,即使是该节点有后端pod,流量也不一定会被转发到该节点上pod,可能会被转发到其他节点上的后端pod。

node1: ap-southeast-1.10.0.1.206 (该节点有后端pod)

image

node1: ap-southeast-1.10.0.1.216 (该节点有后端pod)

image

node3: ap-southeast-1.10.0.0.180 (该节无后端pod)

image

小结

可以访问到目的端

数据链路转发示意图:

image

该图示意了集群内所有ECS都会被加到SLB后端中,从集群外部访问SVC的externalIP(SLB IP)的情况,数据流量可能会被转发到其他节点上

内核协议栈示意图:

内核协议栈示意图已经在 2.4 场景一中已经做了详细描述,此处不再果断篇幅描述。

Conntack 表信息

链路1:

ap-southeast-1.10.0.0.180:

此时数据链路对应示意图中的链路1,可以看到数据链路被转到ap-southeast-1.10.0.0.180 节点,该节点上并没有service的后端pod,通过conntrack 信息,可以看到

src是集群外部客户端IP,dst是节点IP,dport是SVC中的nodeport。并且期望是172.23.96.163 来回包给 10.0.0.180 。通过前述信息,可以得知172.23.96.163 是nginx1-76c99b49df-7plsr pod,部署在ap-southeast-1.10.0.1.206

image

ap-southeast-1.10.0.1.206:

通过此节点conntrack 表,可以看到src是 node ap-southeast-1.10.0.0.180,dst是 172.23.96.163的80 端口,回包也是直接回给 node ap-southeast-1.10.0.0.180.

image

综上可以看到src变换了多次,故在CLuster 模式下,会存在丢失真实客户端IP的情况

链路2:

src是集群外部客户端IP,dst是节点IP,dport是SVC中的nodeport。并且期望是由该ECS上的pod 172.23.96.82 来回包给172.23.96.65,此地址是SLB集群中的一个地址

image

数据链路: 情景一:client -> SLB -> ECS eth0 + ECS nodeport -> cni0 -> vethxxxxx -> ECS1 Pod1 eth0

情景二:client -> SLB -> ECS1 eth0 + ECS1 nodeport -> VPC Routing -> ECS2 eth0 + pod port -> cni0 -> vethxxxxx -> ECS2 Pod1 eth0

  • 数据链路要经过三次内核协议栈,分别是ECS1 OS、 ECS2 OS协议栈 和Pod协议栈

  • ExternalTrafficPolicy为CLuster模式下,kubernetes所有ECS节点都会被加入到SLB的后端虚拟服务器组中,参与SLB的流量转发,此时会存在数据路在集群内被多个ECS转发的场景,该情况下会丢失真实客户端IP的情况

4. 总结

本篇文章主要聚焦ACK 在Flannel模式下,不同SOP场景下的数据链路转发路径。随着微服务化和云原生化,网络场景日趋复杂,作为kubernetes原生的网络模型——Flannel,不同的访问环境,一共可以分为10个SOP场景。通过深入简出的剖析,可以归纳为5个场景,并对这五个场景的转发链路,技术实现原理,云产品配置等一一梳理并总结,这对我们遇到Flannel架构下的链路抖动、最优化配置,链路原理等提供了初步指引方向。接下来将进入到阿里自研的CNI接口Terway模式,也是目前线上集群使用最多的模式,下一系列我们先带来Terway ENI模式的全景解析——《全景剖析阿里云容器网络数据链路(二)—— Terway ENI


本系列联合作者 容器服务 @谢石

作者介绍
目录