在前面几期中,我们介绍了flannel这种常见的容器网络CNI插件:
我们发现,flannel的最大优点是简便,部署和配置工作非常简洁,但它也有一些明显的缺陷和限制:
那么,有没有一种更好的方案,解决flannel的这些问题呢?
让我们回忆一下OpenStack时代——
在OpenStack Neutron中,一开始使用OpenFlow作为各个vSwitch的控制平面,如下图所示:
在Neutron的标准模型中,vSwitch负责以下工作:
让我们将视角切换回flannel的世界。
在flannel的世界里,neutron的角色被替换为etcd,而openflow被etcd的查询操作所取代,其他并没有发生改变。
我们知道,在层次化端口绑定出现后,我们可以使用硬件交换机代替vSwitch进行VXLAN的隧道封装和解封装,并用NetConf+EVPN的纯分布式控制平面代替原OpenFlow的集中式控制平面,如下图所示:
在EVPN+VXLAN的硬件SDN模型中,EVPN让各个硬件交换机的CPU承担了协商建立隧道以及同步MAC/FIB的工作,成为了真正的分布式控制平面,同时,硬件交换机的ASIC(Broadcom Trident 2+或Marvell Armstrong/Alleycat3之后的芯片)接管OVS(vSwitch)承担VXLAN隧道封装和解封装的功能,大大降低了服务器CPU的负担。
很快,这种硬件SDN Overlay方案成为了行业的主流方案。
那么,如何让容器网络也用上硬件SDN Overlay呢?
让我们再翻翻《层次化端口绑定》,回忆一下:
Neutron为了向第三方SDN控制器开放接口,使得第三方SDN控制器能够接管Neutron对VXLAN Overlay隧道封装的定义权,定义了ML2 plugin的标准。第三方SDN控制器向neutron安装自己的ML2 plugin后,就可以实现基于层次化端口绑定的硬件SDN Overlay了。
显然,Kubernetes也定义了这样一种插件——
这就是我们介绍过的CNI。
那么,SDN控制器如何通过CNI插件,实现硬件SDN Overlay呢?
请看下回分解。