35 解读Kubernetes三层网络方案

你好,我是张磊。今天我和你分享的主题是:解读Kubernetes三层网络方案。

在上一篇文章中,我以网桥类型的Flannel插件为例,为你讲解了Kubernetes里容器网络和CNI插件的主要工作原理。不过,除了这种模式之外,还有一种纯三层(Pure Layer 3)网络方案非常值得你注意。其中的典型例子,莫过于Flannel的host-gw模式和Calico项目了。

我们先来看一下Flannel的host-gw模式。

它的工作原理非常简单,我用一张图就可以和你说清楚。为了方便叙述,接下来我会称这张图为“host-gw示意图”。

假设现在,Node 1上的Infra-container-1,要访问Node 2上的Infra-container-2。

当你设置Flannel使用host-gw模式之后,flanneld会在宿主机上创建这样一条规则,以Node 1为例:

$ ip route
...
10.244.1.0/24 via 10.168.0.3 dev eth0

这条路由规则的含义是:目的IP地址属于10.244.1.0/24网段的IP包,应该经过本机的eth0设备发出去(即:dev eth0);并且,它下一跳地址(next-hop)是10.168.0.3(即:via 10.168.0.3)。

所谓下一跳地址就是:如果IP包从主机A发到主机B,需要经过路由设备X的中转。那么X的IP地址就应该配置为主机A的下一跳地址。

而从host-gw示意图中我们可以看到,这个下一跳地址对应的,正是我们的目的宿主机Node 2。

一旦配置了下一跳地址,那么接下来,当IP包从网络层进入链路层封装成帧的时候,eth0设备就会使用下一跳地址对应的MAC地址,作为该数据帧的目的MAC地址。显然,这个MAC地址,正是Node 2的MAC地址。

这样,这个数据帧就会从Node 1通过宿主机的二层网络顺利到达Node 2上。

而Node 2的内核网络栈从二层数据帧里拿到IP包后,会“看到”这个IP包的目的IP地址是10.244.1.3,即Infra-container-2的IP地址。这时候,根据Node 2上的路由表,该目的地址会匹配到第二条路由规则(也就是10.244.1.0对应的路由规则),从而进入cni0网桥,进而进入到Infra-container-2当中。

可以看到,host-gw模式的工作原理,其实就是将每个Flannel子网(Flannel Subnet,比如:10.244.1.0/24)的“下一跳”,设置成了该子网对应的宿主机的IP地址。

也就是说,这台“主机”(Host)会充当这条容器通信路径里的“网关”(Gateway)。这也正是“host-gw”的含义。

当然,Flannel子网和主机的信息,都是保存在Etcd当中的。flanneld只需要WACTH这些数据的变化,然后实时更新路由表即可。

注意:在Kubernetes v1.7之后,类似Flannel、Calico的CNI网络插件都是可以直接连接Kubernetes的APIServer来访问Etcd的,无需额外部署Etcd给它们使用。

而在这种模式下,容器通信的过程就免除了额外的封包和解包带来的性能损耗。根据实际的测试,host-gw的性能损失大约在10%左右,而其他所有基于VXLAN“隧道”机制的网络方案,性能损失都在20%~30%左右。

当然,通过上面的叙述,你也应该看到,host-gw模式能够正常工作的核心,就在于IP包在封装成帧发送出去的时候,会使用路由表里的“下一跳”来设置目的MAC地址。这样,它就会经过二层网络到达目的宿主机。

所以说,Flannel host-gw模式必须要求集群宿主机之间是二层连通的。

需要注意的是,宿主机之间二层不连通的情况也是广泛存在的。比如,宿主机分布在了不同的子网(VLAN)里。但是,在一个Kubernetes集群里,宿主机之间必须可以通过IP地址进行通信,也就是说至少是三层可达的。否则的话,你的集群将不满足上一篇文章中提到的宿主机之间IP互通的假设(Kubernetes网络模型)。当然,“三层可达”也可以通过为几个子网设置三层转发来实现。

而在容器生态中,要说到像Flannel host-gw这样的三层网络方案,我们就不得不提到这个领域里的“龙头老大”Calico项目了。

实际上,Calico项目提供的网络解决方案,与Flannel的host-gw模式,几乎是完全一样的。也就是说,Calico也会在每台宿主机上,添加一个格式如下所示的路由规则:

<目的容器IP地址段> via <网关的IP地址> dev eth0

其中,网关的IP地址,正是目的容器所在宿主机的IP地址。

而正如前所述,这个三层网络方案得以正常工作的核心,是为每个容器的IP地址,找到它所对应的、“下一跳”的网关

不过,不同于Flannel通过Etcd和宿主机上的flanneld来维护路由信息的做法,Calico项目使用了一个“重型武器”来自动地在整个集群中分发路由信息。

这个“重型武器”,就是BGP。

BGP的全称是Border Gateway Protocol,即:边界网关协议。它是一个Linux内核原生就支持的、专门用在大规模数据中心里维护不同的“自治系统”之间路由信息的、无中心的路由协议。

这个概念可能听起来有点儿“吓人”,但实际上,我可以用一个非常简单的例子来为你讲清楚。

在这个图中,我们有两个自治系统(Autonomous System,简称为AS):AS 1和AS 2。而所谓的一个自治系统,指的是一个组织管辖下的所有IP网络和路由器的全体。你可以把它想象成一个小公司里的所有主机和路由器。在正常情况下,自治系统之间不会有任何“来往”。

但是,如果这样两个自治系统里的主机,要通过IP地址直接进行通信,我们就必须使用路由器把这两个自治系统连接起来。

比如,AS 1里面的主机10.10.0.2,要访问AS 2里面的主机172.17.0.3的话。它发出的IP包,就会先到达自治系统AS 1上的路由器 Router 1。

而在此时,Router 1的路由表里,有这样一条规则,即:目的地址是172.17.0.2包,应该经过Router 1的C接口,发往网关Router 2(即:自治系统AS 2上的路由器)。

所以IP包就会到达Router 2上,然后经过Router 2的路由表,从B接口出来到达目的主机172.17.0.3。

但是反过来,如果主机172.17.0.3要访问10.10.0.2,那么这个IP包,在到达Router 2之后,就不知道该去哪儿了。因为在Router 2的路由表里,并没有关于AS 1自治系统的任何路由规则。

所以这时候,网络管理员就应该给Router 2也添加一条路由规则,比如:目标地址是10.10.0.2的IP包,应该经过Router 2的C接口,发往网关Router 1。

像上面这样负责把自治系统连接在一起的路由器,我们就把它形象地称为:边界网关。它跟普通路由器的不同之处在于,它的路由表里拥有其他自治系统里的主机路由信息。

上面的这部分原理,相信你理解起来应该很容易。毕竟,路由器这个设备本身的主要作用,就是连通不同的网络。

但是,你可以想象一下,假设我们现在的网络拓扑结构非常复杂,每个自治系统都有成千上万个主机、无数个路由器,甚至是由多个公司、多个网络提供商、多个自治系统组成的复合自治系统呢?

这时候,如果还要依靠人工来对边界网关的路由表进行配置和维护,那是绝对不现实的。

而这种情况下,BGP大显身手的时刻就到了。

在使用了BGP之后,你可以认为,在每个边界网关上都会运行着一个小程序,它们会将各自的路由表信息,通过TCP传输给其他的边界网关。而其他边界网关上的这个小程序,则会对收到的这些数据进行分析,然后将需要的信息添加到自己的路由表里。

这样,图2中Router 2的路由表里,就会自动出现10.10.0.2和10.10.0.3对应的路由规则了。

所以说,所谓BGP,就是在大规模网络中实现节点路由信息共享的一种协议。

而BGP的这个能力,正好可以取代Flannel维护主机上路由表的功能。而且,BGP这种原生就是为大规模网络环境而实现的协议,其可靠性和可扩展性,远非Flannel自己的方案可比。

需要注意的是,BGP协议实际上是最复杂的一种路由协议。我在这里的讲述和所举的例子,仅是为了能够帮助你建立对BGP的感性认识,并不代表BGP真正的实现方式。

接下来,我们还是回到Calico项目上来。

在了解了BGP之后,Calico项目的架构就非常容易理解了。它由三个部分组成:

  1. Calico的CNI插件。这是Calico与Kubernetes对接的部分。我已经在上一篇文章中,和你详细分享了CNI插件的工作原理,这里就不再赘述了。

  2. Felix。它是一个DaemonSet,负责在宿主机上插入路由规则(即:写入Linux内核的FIB转发信息库),以及维护Calico所需的网络设备等工作。

  3. BIRD。它就是BGP的客户端,专门负责在集群里分发路由规则信息。

除了对路由信息的维护方式之外,Calico项目与Flannel的host-gw模式的另一个不同之处,就是它不会在宿主机上创建任何网桥设备。这时候,Calico的工作方式,可以用一幅示意图来描述,如下所示(在接下来的讲述中,我会统一用“BGP示意图”来指代它):

其中的绿色实线标出的路径,就是一个IP包从Node 1上的Container 1,到达Node 2上的Container 4的完整路径。

可以看到,Calico的CNI插件会为每个容器设置一个Veth Pair设备,然后把其中的一端放置在宿主机上(它的名字以cali前缀开头)。

此外,由于Calico没有使用CNI的网桥模式,Calico的CNI插件还需要在宿主机上为每个容器的Veth Pair设备配置一条路由规则,用于接收传入的IP包。比如,宿主机Node 2上的Container 4对应的路由规则,如下所示:

10.233.2.3 dev cali5863f3 scope link

即:发往10.233.2.3的IP包,应该进入cali5863f3设备。

基于上述原因,Calico项目在宿主机上设置的路由规则,肯定要比Flannel项目多得多。不过,Flannel host-gw模式使用CNI网桥的主要原因,其实是为了跟VXLAN模式保持一致。否则的话,Flannel就需要维护两套CNI插件了。

有了这样的Veth Pair设备之后,容器发出的IP包就会经过Veth Pair设备出现在宿主机上。然后,宿主机网络栈就会根据路由规则的下一跳IP地址,把它们转发给正确的网关。接下来的流程就跟Flannel host-gw模式完全一致了。

其中,这里最核心的“下一跳”路由规则,就是由Calico的Felix进程负责维护的。这些路由规则信息,则是通过BGP Client也就是BIRD组件,使用BGP协议传输而来的。

而这些通过BGP协议传输的消息,你可以简单地理解为如下格式:

[BGP消息]
我是宿主机192.168.1.3
10.233.2.0/24网段的容器都在我这里
这些容器的下一跳地址是我

不难发现,Calico项目实际上将集群里的所有节点,都当作是边界路由器来处理,它们一起组成了一个全连通的网络,互相之间通过BGP协议交换路由规则。这些节点,我们称为BGP Peer。

需要注意的是,Calico维护的网络在默认配置下,是一个被称为“Node-to-Node Mesh”的模式。这时候,每台宿主机上的BGP Client都需要跟其他所有节点的BGP Client进行通信以便交换路由信息。但是,随着节点数量N的增加,这些连接的数量就会以N²的规模快速增长,从而给集群本身的网络带来巨大的压力。

所以,Node-to-Node Mesh模式一般推荐用在少于100个节点的集群里。而在更大规模的集群中,你需要用到的是一个叫作Route Reflector的模式。

在这种模式下,Calico会指定一个或者几个专门的节点,来负责跟所有节点建立BGP连接从而学习到全局的路由规则。而其他节点,只需要跟这几个专门的节点交换路由信息,就可以获得整个集群的路由规则信息了。

这些专门的节点,就是所谓的Route Reflector节点,它们实际上扮演了“中间代理”的角色,从而把BGP连接的规模控制在N的数量级上。

此外,我在前面提到过,Flannel host-gw模式最主要的限制,就是要求集群宿主机之间是二层连通的。而这个限制对于Calico来说,也同样存在。

举个例子,假如我们有两台处于不同子网的宿主机Node 1和Node 2,对应的IP地址分别是192.168.1.2和192.168.2.2。需要注意的是,这两台机器通过路由器实现了三层转发,所以这两个IP地址之间是可以相互通信的。

而我们现在的需求,还是Container 1要访问Container 4。

按照我们前面的讲述,Calico会尝试在Node 1上添加如下所示的一条路由规则:

10.233.2.0/16 via 192.168.2.2 eth0

但是,这时候问题就来了。

上面这条规则里的下一跳地址是192.168.2.2,可是它对应的Node 2跟Node 1却根本不在一个子网里,没办法通过二层网络把IP包发送到下一跳地址。

在这种情况下,你就需要为Calico打开IPIP模式。

我把这个模式下容器通信的原理,总结成了一张图片,如下所示(接下来我会称之为:IPIP示意图):

在Calico的IPIP模式下,Felix进程在Node 1上添加的路由规则,会稍微不同,如下所示:

10.233.2.0/24 via 192.168.2.2 tunl0

可以看到,尽管这条规则的下一跳地址仍然是Node 2的IP地址,但这一次,要负责将IP包发出去的设备,变成了tunl0。注意,是T-U-N-L-0,而不是Flannel UDP模式使用的T-U-N-0(tun0),这两种设备的功能是完全不一样的。

Calico使用的这个tunl0设备,是一个IP隧道(IP tunnel)设备。

在上面的例子中,IP包进入IP隧道设备之后,就会被Linux内核的IPIP驱动接管。IPIP驱动会将这个IP包直接封装在一个宿主机网络的IP包中,如下所示:

图5 IPIP封包方式

其中,经过封装后的新的IP包的目的地址(图5中的Outer IP Header部分),正是原IP包的下一跳地址,即Node 2的IP地址:192.168.2.2。

而原IP包本身,则会被直接封装成新IP包的Payload。

这样,原先从容器到Node 2的IP包,就被伪装成了一个从Node 1到Node 2的IP包。

由于宿主机之间已经使用路由器配置了三层转发,也就是设置了宿主机之间的“下一跳”。所以这个IP包在离开Node 1之后,就可以经过路由器,最终“跳”到Node 2上。

这时,Node 2的网络内核栈会使用IPIP驱动进行解包,从而拿到原始的IP包。然后,原始IP包就会经过路由规则和Veth Pair设备到达目的容器内部。

以上,就是Calico项目主要的工作原理了。

不难看到,当Calico使用IPIP模式的时候,集群的网络性能会因为额外的封包和解包工作而下降。在实际测试中,Calico IPIP模式与Flannel VXLAN模式的性能大致相当。所以,在实际使用时,如非硬性需求,我建议你将所有宿主机节点放在一个子网里,避免使用IPIP。

不过,通过上面对Calico工作原理的讲述,你应该能发现这样一个事实:

如果Calico项目能够让宿主机之间的路由设备(也就是网关),也通过BGP协议“学习”到Calico网络里的路由规则,那么从容器发出的IP包,不就可以通过这些设备路由到目的宿主机了么?

比如,只要在上面“IPIP示意图”中的Node 1上,添加如下所示的一条路由规则:

10.233.2.0/24 via 192.168.1.1 eth0

然后,在Router 1上(192.168.1.1),添加如下所示的一条路由规则:

10.233.2.0/24 via 192.168.2.1 eth0

那么Container 1发出的IP包,就可以通过两次“下一跳”,到达Router 2(192.168.2.1)了。以此类推,我们可以继续在Router 2上添加“下一条”路由,最终把IP包转发到Node 2上。

遗憾的是,上述流程虽然简单明了,但是在Kubernetes被广泛使用的公有云场景里,却完全不可行。

这里的原因在于:公有云环境下,宿主机之间的网关,肯定不会允许用户进行干预和设置。

当然,在大多数公有云环境下,宿主机(公有云提供的虚拟机)本身往往就是二层连通的,所以这个需求也不强烈。

不过,在私有部署的环境下,宿主机属于不同子网(VLAN)反而是更加常见的部署状态。这时候,想办法将宿主机网关也加入到BGP Mesh里从而避免使用IPIP,就成了一个非常迫切的需求。

而在Calico项目中,它已经为你提供了两种将宿主机网关设置成BGP Peer的解决方案。

第一种方案,就是所有宿主机都跟宿主机网关建立BGP Peer关系。

这种方案下,Node 1和Node 2就需要主动跟宿主机网关Router 1和Router 2建立BGP连接。从而将类似于10.233.2.0/24这样的路由信息同步到网关上去。

需要注意的是,这种方式下,Calico要求宿主机网关必须支持一种叫作Dynamic Neighbors的BGP配置方式。这是因为,在常规的路由器BGP配置里,运维人员必须明确给出所有BGP Peer的IP地址。考虑到Kubernetes集群可能会有成百上千个宿主机,而且还会动态地添加和删除节点,这时候再手动管理路由器的BGP配置就非常麻烦了。而Dynamic Neighbors则允许你给路由器配置一个网段,然后路由器就会自动跟该网段里的主机建立起BGP Peer关系。

不过,相比之下,我更愿意推荐第二种方案

这种方案,是使用一个或多个独立组件负责搜集整个集群里的所有路由信息,然后通过BGP协议同步给网关。而我们前面提到,在大规模集群中,Calico本身就推荐使用Route Reflector节点的方式进行组网。所以,这里负责跟宿主机网关进行沟通的独立组件,直接由Route Reflector兼任即可。

更重要的是,这种情况下网关的BGP Peer个数是有限并且固定的。所以我们就可以直接把这些独立组件配置成路由器的BGP Peer,而无需Dynamic Neighbors的支持。

当然,这些独立组件的工作原理也很简单:它们只需要WATCH Etcd里的宿主机和对应网段的变化信息,然后把这些信息通过BGP协议分发给网关即可。

总结

在本篇文章中,我为你详细讲述了Fannel host-gw模式和Calico这两种纯三层网络方案的工作原理。

需要注意的是,在大规模集群里,三层网络方案在宿主机上的路由规则可能会非常多,这会导致错误排查变得困难。此外,在系统故障的时候,路由规则出现重叠冲突的概率也会变大。

基于上述原因,如果是在公有云上,由于宿主机网络本身比较“直白”,我一般会推荐更加简单的Flannel host-gw模式。

但不难看到,在私有部署环境里,Calico项目才能够覆盖更多的场景,并为你提供更加可靠的组网方案和架构思路。

思考题

你能否能总结一下三层网络方案和“隧道模式”的异同,以及各自的优缺点?

感谢你的收听,欢迎你给我留言,也欢迎分享给更多的朋友一起阅读。