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

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 ？

一台机器有自己的 MAC 地址，常规的主机上有自己的 IP ， MAC 地址跟 IP 之间是有关联的，也有三层的概念在里边，但是这是主机的网络，容器起来以后也是有 MAC 地址的，但是它是一个虚拟的 MAC 地址，如何获得一个真实的 IP 或者想要给它分配的 IP ，就引出了一个概念—— L3 的虚拟网络，可以在没有真实 MAC 地址或者 MAC 地址是一样的情况下能给它分配不同的 IP 。 Linux 的 Kernel 有 Filter 的概念，可以对数据流进行转换，在前面可以打包头，我们就可以在 Linux 完整的基础之上在路由的规则上做判断， Linux Bridge 模式的话是可以造 IP 的， Calico 项目源码的基础就是 Linux 的这个能力。之所以每个容器之间有隔离的作用，是因为它可以对每一个容器分不同的网段，网段之间是隔离的，本来两个网段之间就没有路由规则，无法相通。

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

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

互联网公司普遍是内存比较小但机器比较多，常常一两千台机器；但有的传统企业用的是大型机或者用的机器都比较大，他们的机器四五台机就能组成一个网络，内存比较多，一台机器可以跑两三百个容器，四五台机器能跑几千个容器，这就是 Clico 和一些第三方的解决方案要解决的问题——管理 IP 的网段，因为 IP 地址是有限的，并且真实的网段是一套，而所有的这些分的 IP 的网段也是真实的，要去管理它的冲突。现在大家想到的是自己搞一个 IP 的管理界面，对 IP 进行管理把它固定住，但当容器越来越多的时候，就会有很多问题。

针对数据中心东西向的解决方案， Calico 提出的一种方法是基于 BGP 协议。 BGP 协议是对路由规则进行控制，也就是说在没有 MAC 地址的情况下，路由有路由表，路由表多了以后有两件事，第一是要广播，第二是这个路由表大了，软件模拟的方式会有性能瓶颈，并且还要做精细化的访问控制。因为两个网段之间用的虚拟网段，有可能会冲突，一两个网段的时候可能没有问题，当几十个 APP 之间隔离的时候两个虚拟网段用的可能是同样的 IP 地址，要保证它们两个不通，如果通的话还要保证两个 IP 不能冲突。那么有没有更好的方式？有，就是 MAC Vlan ——用主机的方式管理虚机。

这与 Host 的模式（不用自己的虚拟网络，用原生的主机模式网络）相比，只是加了一层 MAC 地址的管理。但是它有一个比较大的问题是对硬件有依赖，因为 MAC 是要转 IP 的，而 IP 地址一定是有限的， MAC 地址也是有限的，如果有冲突都是靠硬件来控制的，它并不能很轻易地上云，云端 MAC 地址不受控制，基本上是在私有云的基础上用 MAC Vlan 的方法去做。对于 Mesos 的解决方案我们希望的是通用型的，有一个网络标准 CNI ， Calico 是比较灵活的而有保障的。这是今天推荐这样一个方案的原由。

网络很复杂，讲讲基本功 在学习网络的过程中，有几个知识比较重要。首先，什么是三层网络？其实就是二层交换，三层路由。当前的路由器已经非常先进， Overlay 最大的一个特点就是利用了路由这样一个基本的知识点。大家会看到从 S0 这一块进来以后一定是一个路由表，路由表之后会制定一些 policy ，然后到每一个网卡上再去劫持，去做一个路由表和一些规则，到机器上以后这个 Brige 有了一个新的网卡，是不依赖于 MAC 地址的，它的好处在于可以连接一个非常大的网，容器可以随意的起，起几百个容器都能连起来，我们只需把网配好就可以了。 但是传统 Overlay 因为功能太强、太先进，一定要打无数个包头才能从最远端到里边。 Vxlan 以最新代表的 SDN 的网络非常先进，但是软件模拟这种网络是非常脆弱的，规模越大效率越低，因为最简单的问题就要解包、拆包，拆到最后拆到 MAC 地址和 IP 。网络数据包有拆包、解包的过程，只有让它少一点拆包解包的能力，这样速率才会高。通俗地说，当前所有用 Doker 网络的解决方案都是有损耗的，除非不使用或者使用 Vxlan ， Vxlan 也没有用虚拟网络，所有的虚拟网络都是有损耗的，所以目前无损耗的方式是不可能做到的。

这个包头或者路由表在规则少、规模小的时候，效率还是很高的。上图两行红字，第一个是 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 做法就更先进一点，它的做法就是点对点地去刷，容器起来的时候去刷，局限性是只能在一个数据中心里面做这件事，因为它是一个实验型的项目，我们尚不清楚它的性能和规模，仅在此与大家分享一下。谢谢大家。