在上期，我们提到，大型云计算平台的容器网络，需要考虑的一个关键因素，是应用调度层(容器)和资源层(虚拟机)的紧密结合。
经典的Overlay隧道方式打通的容器网络如下图：
这张图我们再复习一遍：两个Kubernetes的Worker Node通过VXLAN隧道打通，这样，无论两个Worker Node之间经过了多少跳，只要是IP可达，这两个容器就可以通信。
在基于openstack的中小型云平台中，这也是一种常见的Kubernetes网络实现方式。由于中小型云平台中，Openstack一般采用VLAN方式进行子网之间的隔离，宿主机之间不通过VXLAN进行打通，因此，Kubernetes Flannel等CNI插件增加一个VXLAN头部尚可以接受。
但是，在2016年以后，随着云计算平台的扩大，无论是Openstack云平台，还是大中型公有云平台，基于VXLAN或GRE的隧道封装实现VPC已成为业界共识。显然，在隧道中再封装隧道不是一个好的方案。
另一种打通容器互访的方式为BGP网络，此种网络打通的方式以calico为代表：
图中，连接各node之间的网络各节点需要通过BGP学习到各个node下，pod的IP地址信息，才能够正确转发指向每个Pod IP地址的数据包。在公有云中，这需要vSwitch学习来自Node的BGP，如下图所示：
图中，是公有云的vSwitch配合容器平台进行BGP路由学习和宣告的示意图。显然，这对公有云的vSwitch也会有较大的改造。
话分两头。上期我们讲到，虽然苏联在赫鲁晓夫等修正主义分子的破坏下最终不复存在，但苏联建国初期为理想奋斗的精神却在一系列文艺作品中得以持久化存储和组播式传播。《钢铁是怎样炼成的》就是其中的代表。
在《钢铁是怎样炼成的》中，保尔和冬妮娅少年时青梅竹马，冬妮娅推荐保尔读《牛虻》，启蒙了保尔心中的革命火种。但由于冬妮娅往往只考虑到两个人的局部得失，而保尔考虑的却是为人类解放而进行的斗争，两人最终分开，保尔在去黑海疗养时，选择了与自己共同为世界上最壮丽的事业奋斗终身的伴侣达雅。他们的故事随第聂伯河传遍广淼的乌克兰大平原，也被铭刻在理想主义者们的心中。
实际上，在大型公有云中，vSwitch的控制面设计也与保尔的思想类似，为了降低BGP学习对vSwitch CPU的消耗，vSwitch之间并没有采用BGP EVPN的方式来同步虚拟机入网、离网和迁移等信息，而是进行通盘考虑，在SDN控制器上统一下发转发信息，解放了百万计的服务器CPU。
那么，能否让大型公有云的SDN控制器对接公有云的容器网络，实现类似Calico的三层转发平面呢？
在业界TOP的TX云中，这一方案叫做Global Router。它的实现如下图所示：
图中，云服务器CVM作为Kubernetes的工作节点，两台CVM P和Q在VPC内的IP地址分别为10.100.100.50和10.100.200.50。CVM P上运行的Pod A和Pod B的IP地址为172.17.10.161和172.17.10.162；CVM Q上运行的Pod C和Pod D的IP地址为172.17.11.161和172.17.11.162。
Global Router的实现是，在每台CVM上有一个Global Router模块，负责实现三层转发，而不进行隧道封装。只有数据包来到CVM宿主机上的vSwitch的时候，才进行GRE封装，进入VPC overlay网络。Global Router CNI插件会在Kubernetes创建容器的时候，就对VPC内的各个Global Router下发转发信息，同时，SDN控制器也会让CVM所在宿主机的vSwitch能够封装和解封装相关的流量。
Global Router是一种非常优雅的设计，可以避免二次Overlay封装，还可以实现容器和虚拟机之间IP可达。但是，Global Router的软转发对容器之间互通的时延会有一定影响，有没有较好的方案消除这一影响呢？
请看下期。
