在前面几期中，我们介绍了flannel这种常见的容器网络CNI插件：
容器网络硬核技术内幕 (12) 美丽的法兰绒 (上)
容器网络硬核技术内幕 (13) 美丽的法兰绒 (中)
容器网络硬核技术内幕 (13) 美丽的法兰绒 (下)
我们发现，flannel的最大优点是简便，部署和配置工作非常简洁，但它也有一些明显的缺陷和限制：
- flannel无法支持多租户。也就是说，如果数据中心中运行了业务A，业务B，业务C……它们本应当不知道对方的存在，但如果使用了flannel，各个业务的管理员在配置自身使用的IP地址时，需要考虑到不与其他的业务发生冲突。对于出租资源的数据中心，如公有云场景，这是难以接受的。
- flannel使用etcd作为分布式控制平面，但由于etcd本身的限制，其本质上是集中式控制平面，所有的MAC和ARP学习都需要由etcd节点处理。在kubernetes的节点规模上升到一定程度后，etcd会成为扩容的瓶颈。
- flannel的VXLAN overlay封装和解封装由OVS执行，会消耗各节点的CPU资源，总体上增加数据中心的CAPEX。
那么，有没有一种更好的方案，解决flannel的这些问题呢？
让我们回忆一下OpenStack时代——
在OpenStack Neutron中，一开始使用OpenFlow作为各个vSwitch的控制平面，如下图所示：
在Neutron的标准模型中，vSwitch负责以下工作：
- 收到数据包时，查询流表，对于已知的在宿主机内转发的数据包，将其转发到目标VM；
- 如果数据包需要发送到在远端宿主机上的VM，封装VXLAN隧道发送，接收到来自远端vSwitch的数据包时则解开VXLAN封装，将里面封装的有效数据包送到其目标VM；
- 对于未知MAC/IP，不知道应当送到哪里的数据包，会被送到Neutron控制器，Neutron通过OpenFlow下发流表给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呢？
请看下回分解。
