云计算网络技术内幕 (20) 那鹰原来是只鸡

前几期，我们介绍了容器网络的开源实现Calico/Flannel和公有云实现TKE Global Router和VPC-CNI，其实现也是各有特色的。

随着云原生技术的逐渐普及，部分政企和金融客户也跟随互联网大厂的脚步，开始将业务进行云原生改造，并且在自身的生产系统中部署商业化的容器平台，将大型公有云容器平台进行私有化部署，也就是使用与公有云同构的专有云，也成为了政企和金融业务的首选。

专有云的部署有两种模式：IaaS与PaaS一体模式；IaaS与PaaS解耦模式；

前者可以理解为公有云的整体私有化部署，容器平台在此种模式中工作方式与公有云没有本质区别。如TCE中的TKE网络实现，与腾讯公有云的TKE基本一致。而另一种场景则增加了复杂性。

这是由于，IaaS与PaaS解耦后，包括容器平台、中间件、微服务、数据库等PaaS套件独立输出，在第三方IaaS上部署是难以避免的。在这种情况下，容器平台的工作节点有可能为物理服务器，也有可能为虚拟机。而容器工作节点之间的网络连接更为复杂，有可能是物理服务器通过以太网交换机二层直通，有可能是物理服务器之间三层可达，甚至还有可能是虚拟机通过其他云平台的Overlay网络互通。

那么，如何在如此复杂的IaaS环境中实现容器网络的高效灵活处理，就成了一个让工程师们发际线急剧后移的问题。

我们在前面提到，常见的开源容器实现有calico和flannel。对于此种场景，二者各有难以绕过的弊端。

我们再复习一遍calico的数据平面与控制平面架构：

如图，calico的数据平面需要网络中各节点能够实现三层转发，并且与bird建立BGP连接，作为RR Client (什么是BGP RR？请大家学习本公众号以前的内容)。显然，对于第三方的IaaS平台，这是过于艰巨的适配工作。

而flannel的控制平面较为简单，不需要BGP路由宣告，但需要在Kubernetes的工作节点上进行隧道的封装和解封装。

如图，flannel实际上是将K8S工作节点作为VXLAN VTEP，进行二次封装。对于VMWare vSphere或H3C UIS这样的虚拟化/超融合环境而言，此种数据平面封装方式尚可接受，但对于Openstack等私有云环境，在基于VXLAN的VPC内，再进行VXLAN封装，此种嵌套封装增加了100Byte的开销，且flannel还有不支持network policy的缺陷，这些都是flannel容器网络方案与客户需求之间的差距。

我们小结一下，容器平台在私有化输出，并与IaaS解耦时，对容器网络的需求是：

1. 与IaaS网络解耦，不需要让IaaS网络参与BGP路由发布和计算这些麻烦的事情；
2. 尽量提升网络转发效率，不要使用VXLAN这种开销过大的隧道协议；
3. 支持network policy；

对于这些要求，腾讯专有云TCS给出了版本最佳答案：cilium。

TCS是将腾讯公有云上容器平台及PaaS能力私有化输出的敏捷PaaS平台，其工作环境较为复杂，有可能在物理服务器上直接部署，也有可能需要在第三方IaaS环境下部署，第三方IaaS仅提供IP可达的虚拟机作为容器平台的Master Node和Worker Node。

在这些复杂的需求下，TCS选择了cilium作为主要的容器网络实现方式。cilium的底层机制是内核可编程机制ebpf。

ebpf是什么高科技呢？

让我们先看一个小故事。

有天，一位小朋友告诉妈妈：我今天发现了一只鹰！

妈妈问：鹰是什么样呀？

小朋友说：那鹰长得胖胖的，头上有红色的冠子，脖子和尾巴是彩色的毛，爪子是黄色的。

妈妈想了想说：你说的那鹰是不是鸡？

小朋友说：哈哈！那鹰的确是只鸡。

正如小朋友眼里的那鹰其实是只鸡一样，ebpf也并非什么新型的黑科技，而是可以在古老的freebsd中找到其技术根源。

请看下期分解。