容器网络硬核技术内幕 (11) 西直门桥的传说

上回我们说到，bridge插件在kubernetes的node之间，为pod的互联互通架起了简单直接的一座大桥，像南京长江大桥一样实现了天堑变通途。

随着历史的车轮转动，当一位老人在祖国的南海边画下那个圈的时候，一座神奇的桥，在北京拔地而起，这就是——西直门立交桥。

上错图了，应该放这个：

还是不对，应该是这个：

为什么要修建如此复杂的立交桥呢？

当然，是因为简单的桥梁无法满足复杂交通的需求。

类似市政交通的世界里那样，在容器的世界里，使用bridge插件，作为kubernetes的网络实现，虽然简单而直接，但有两个问题：

一、bridge这种互通方式，本质上是将所有pod放在一个二层域内，没有任何子网之间的隔离，任何BUM数据包都会被复制到所有pod。当pod数超过500，BUM泛洪数量是不可接受的。

二、bridge这种互通方式，缺少“网关”(gateway)，这会让各个子网之间无法通信，也就是说，nginx的pod无法访问tomcat的pod！

这两个问题实际上是有解的。

对于第一个问题，bridge是支持VLAN的。在配置文件中，有一个VLAN选项，通过这个选项，可以让bridge配置VLAN access和VLAN trunk：

如图所示，我们可以为nginx, tomcat和mysql分配三个VLAN，对应它们各自的CIDR。这样，通过VLAN将广播域划分开，第一个问题就得以解决了。

第二个问题也是可以解决的。

bridge除了二层工作方式，还有三层工作方式。

它的三层工作方式配置文件如下：

{

"cniVersion": "0.3.1",

"name": "mynet",

"type": "bridge",

"bridge": "mynet0",

"isDefaultGateway": true,

"forceAddress": false,

"ipMasq": true,

"hairpinMode": false,

"ipam": {

"type": "host-local",

"subnet": "172.17.11.0/24"

}

}

和前面的配置文件相比，多了一些配置，但最核心的是这个地方：

isDefaultGateway：设置为true以后，bridge就可以工作在三层模式，具有三层转发的能力；

ipam字段配置了子网172.17.11.0/24，这样能够为VLAN内的pod分配地址。

需要注意一个细节：hairpinmode，如果打开这个开关，会导致bridge本身不做任何数据包交换转发，而是将数据包全部送到TOR交换机处理。这个问题将来再阐述。

通过这种方式，可以实现如下的组网——

如图，左边的node上运行了3个pod，每个pod均运行nginx，而右边的node上运行了3个pod，每个pod均运行tomcat。

但是，我们知道，实际上，为了让每个宿主机上的资源得以充分利用，容器编排平台会倾向于将不同的应用放在同一个node，让同一个node上运行着内存密集型、CPU密集型和磁盘I/O密集型的Pod，将宿主机上的资源压榨到极限。这时候，无论是使用bridge的二层模式，还是三层模式，都有无法满足pod之间互通需求的地方。

因此，人们开发了一个新的CNI插件——flannel。

请看下回分解。