老肖实录分享 | Mesos容器网络解决方案

Posted 2021-04-24 优云数智

CNUTCon2016已经落下帷幕，但是其精彩内容我们还在久久回味。今天小数为大家带来的是数人云CTO肖德时在容器大会上的演讲实录，从理论说起，将实践进行到底，让我们一起来探讨容器网络的问题以及解决：）

Mesos是数人云的主要的技术栈之一，并且我们很早就开始在实践Mesos应用。从数人云的角度，我们希望容器的快速分发能够帮助客户实现快速交付。现在Mesos社区的发展非常快，Mesos有一个重要的特性Unified Container，让Mesos可以交付容器。而接下来有一个更热的话题—— 一容器一IP，在当前容器圈用网络方案如何解决这个问题，大家各显神通，但是真正能把网络和容器说清楚的并不是特别多，结合数人云长时间的积累和实践，在这里我想跟大家一起探讨容器的网络以及Mesos的解决方案，为大家提供一个参考。

 

Mesos的网络问题

 

Mesos 1.0其实已经有了一个完整的容器Interface的规范， CNCF（Cloud Native Computing Foundation）提供了Container Network Interface的接口，希望在Mesos社区里规范网络的使用，让大家有一个接口能够复用网络。刚刚发布的Mesos 1.0会遇到一些问题。最常见的就是我们无法逾越的一容器一IP，对于这个问题大家都有各自的看法，但是Mesos的过程里面是sandbox，是没有IP的概念的，所以要思考如何用容器的方式获得IP。

                                        

第二，有了IP接着会出现服务发现的问题，什么是服务发现？最简单的是DNS，一个名字对多个IP。第三，有了网络之后，所有的数据之间有了联系，它们之间如何隔离是一个问题。例如，有一个数据库专门为业务A使用，另外一个数据库供业务B使用，就有两个Wordpress，这两个多租户之间没有任何的联系，我们希望它们之间的网络是隔离的， Mesos有一个可以让大家立即使用的解决方案是Calico这个项目，虽然也有商业的公司在做这个项目，但是它的源码和思想是可以被复用的，所以我这次主要是与大家分享一容器一IP实现的方式。

 

实现一容器一IP为什么选择Calico？

 

 

Mesos有一个CNI的支持为什么非常重要？之前使用Mesos和Doker的时候，我们有很多方式可以获得IP，但这些方式对于Mesos生态圈里面来说很难有规范， Mesos发展到如今已经把Doker去掉，对于网络这部分它需要一个规范，这个规范就是CNI规范。CNI规范是一个Json，这个Json非常简单是一个很好的语义，而且它可以支持IPV4，以及之后的IPV6。一个配置文件能够描述整个网络结构已经足够，有了CNI之后有很多种实现，Calico只是其中一种，大家会看到有硬件的、有Contive、有Weave，有Vxlan的模式等等，它们内部其实都有Overlay的模式。

 

Mesos本身是为数据中心设计的一套集群，需要了解数据中心的网络结构有两个非常关键的指标——南北的数据流和东西的数据流，南北的数据流就是从数据中心外面到数据中心内部的数据流。网络结构可能有路由器，网关，下面可能有LoadBalance，但它跟容器相关的网络是没有关系的。我们通过容器的方式，类似于是想水平扩展的，基于这个网络的概念，我们提出想要一个比较复杂的网络结构。

 

 

网络很复杂，讲讲基本功

 

这个包头或者路由表在规则少、规模小的时候，效率还是很高的。上图两行红字，第一个是Overlay对Overlay的，这是纯的Vxlan的网络，像Docker的Swarm就用这种原生的网络创建，它的问题就在于它是虚拟的去转换，所以整个网络非常弱，损耗只能到40%，60%都损耗掉了。并不是说网络不先进，瓶颈在于它实现的是一个参考，如果用硬件或第三方的结构，用Docker Swarm解决不了，那么网络基本上是不可用的。第二个是Calico的Overlay，损耗差不多也是百分之十几，是目前为止我们看到的一个最好的方式。这个基础数据来自Percona这个公司，它做的mysql发行版，在Master和Slave之间做同步，数据量增大这个瓶颈才能压测出来，从而得到这个基础数据报告。

 

Doker非常好用，但是Doker内置Swarm的特性，Doker Swarm就是两行命令就能创建的网络，非常简单。这个网络非常适合在测试环境和在单机的模式下调试网络，它有自己的DNS、名字、网络IP，也可以自己管理，非常方便。但是到了生产级别用网络Mesos容器方案的时候，Calico这个方案可以帮助大家更好地理解和解决这个问题。

 

Calico是如何做的？

 

在上图中，它的原理是IP Table，使用了Calico的组件，用BGP去做，其中一个关键点就是它要保存这个路由规则，还要刷每台机器的路由。它首先要用etcd保存这些信息，因为本地无法存储，要保证一致性。第二，它的路由表要刷给别的机器，每台机器都要去传，所以每台机器都是跟etcd有关联的，触发BGP去刷。它是无中心的，每台机器刷完以后，这边路由表规则一变，Mesos所有机器的路由表就变了，看起来好像网是通了。因为每台机器出来的时候走的是S0的IP，到那边的时候也是S0，但是路由做了规则转换，所以两边都是通的，能跨主机的IP实现了这样的过程。

 

这里它做了一个小小的手术，因为网络结构越复杂，要对封包做的越多，在这个网段里面跳一下的时候需要给消息包头打个标签，IP要打不同的标签，才能到那个网络里面。它做了一个权衡，认为网络不要太多，可能就是一百台机器的规模，因为有ARP广播，广播风暴在网络里面非常常见，Mesos本身又不管网络。 Calico现在的做法就是在中间加了一个Route Reflector。BIRD也是第三方的，是Linux路由表的一个存储，它利用第三方的存储来存储自己的路由规则，然后保证这个路由规则能够被其它方主动去抓，这样就从原来推的方式变成抓的方式，简单地解决了这个问题。Mesosphere就是参考这个实现了一套类似于Calico的网络方案，叫Minuteman，也是开源的，在open dcos上面有这样一个方案，大家可以去参考。这个就是Calico具体的实现。

 

对于Mesos的网络结构，要有Framework的概念，也要有Slave、Executer的概念。Launch Calico做了一个插件安装在每台机器上，之后Framework调用、起一个任务的时候会劫持和触发IP规则的启用，Calico自己有IP management，下发到Slave那有一个隔离模块，做策略的隔离，获得IP做一个Policy，然后做一个隔离。这一块就是调用IP Table、IP Set去做，做完以后再去更新Master信息放到Zookeeper里面。然后获得了一个Task的IP。尤其像现在没有Doker的情况下，UnifiedContainerize 更是这种模型了。其实安装的组件就是一个Calico的BGP Agent，以及一个Felix，Agent刷本地的，Felix去刷别人的。

 

最终，Mesos目前真实的IP网络结构就是这样一个模型：每台机器上面有一个小路由器，我把它定义为是一个路由器，其实就是路由规则，它保存完以后每台机器里的容器的IP是可以不一样的，也可以一样的，但是左边的这台机器的IP跟右边这台机器的IP是不通的，路由表虽然刷了但是不通的。它可以通过广播的方式告诉右边的，右边再刷一下自己的路由规则，这边一访问的时候，因为用IP Table把它的Package切了，就类似于Router把它改了，destination也改了，传到另外一台机器上，那边也因为路由规则相应的做了转换，所以相应的加了路由的包到里边，容器知道这个数据包了就可以接通。Router这边它是模拟的、虚拟的，机器越多，由于它要主动去推，其性能就会下降。Calico的方式就是在外面再架一个中央路由器，然后让用户刷，再从中央路由器去取，这样就减少广播的节点。

 

Mesosphere最新的做法，是用的Erlang的模型做了一个P2P的网络结构。好处在于可以点对点地刷路由，也就是说这两台机器的应用之间有关联才去刷，如果没有关联，像Calico就刷一次，每个表都要刷，因为它不知道用户会不会在下一秒去启动新的容器，所以这种结构是传统的网络结构。但是Mesosphere的Minuteman做法就更先进一点，它的做法就是点对点地去刷，容器起来的时候去刷，局限性是只能在一个数据中心里面做这件事，因为它是一个实验型的项目，我们尚不清楚它的性能和规模，仅在此与大家分享一下。谢谢大家。

相关阅读

老肖语录之

来个招聘