从0.25到1.0，中小企业Mesos网络和存储的填坑实践

看完海外大型企业的Mesos容器技术实践，让咱们视线回到国内。今天是 数人云容器三国演义Meetup嘉宾演讲实录第一弹。中小企业是如何解决Mesos使用过程当中种种问题的？Acttao技术总监何威威来告诉你答案——

今天与你们分享的是中小企业的Mesos实践中遇到的网络和存储方面的具体问题。

概述

首先介绍一下Acttao的实践状况。Acttao如今主要运行两个Mesos集群，一个用于测试环境，另外一个用于生产环境。测试环境部署在KVM虚拟机里面，生产环境在阿里云。以前还有一个OpenStack的测试环境，后来撤掉了。有了Mesos集群之后，咱们在开发过程当中引入了CI/CD，CI/CD要求开发人员能很方便的管理无状态的Web服务，一个有状态相似于MySQL、Redis等的服务，还要求Web服务可以方便的找到数据库服务，这是要解决这三个问题。

要解决这些问题，须要咱们在Mesos的容器里面实现一容器一IP，对于有状态的容器须要跨主机的Volume服务，以及服务发现。

Mesos容器网络

说一下Mesos网络的方案。按照时间有三个阶段，第一个阶段在Mesos 0.25以前，在这以前Docker自己没有容器的扩展，第二个阶段是Mesos0.25到1.0之间，第三个阶段就是如今1.0版本以后。Mesos 0.25以前这个方案基本上是空白的，大部分都要手动运行脚本，以空网络起一个Docker容器，而后再运行一些好比建立网络设备、配置IP。那时有一个Powerstrip原型的工具，其原理是替代Docker API作一些扩展，使用这种工具给Mesos容器加IP基本不会有改动，经过Mesos的API就能够实现一容器一IP。

在Mesos0.25到1.0版本之间，这时Docker推出了网络扩展功能，Docker容器有了原生的网络扩展支持。典型的第三方插件有Weave、Calico等。咱们经过MarathonAPI能够直接实现建立的容器有一个IP。

1.0以后Mesos原生支持了CNI网络，经过Unified Container，不管是Mesos的容器仍是Docker的容器、AppC的容器，都很容易作到一个容器一个IP。

在Mesos支持CNI以前，为了实现IP per container，Acttao最后选择了Weave。没有使用Docker容器的扩展，而是选择Weave Proxy，相似于0.25以前的方案，由于它很容易集成。Weave的Proxy方式有DNS的服务发现，集成较简单，Weave起一个Router，而后Proxy起开，起开之后在Mesos的slave设置Docker socket走Weave Proxy的socket就能够了。

当时没有选择Docker Libnetwork的扩展方式，由于那时须要为每个Docker配一个外部存储，这也是刚才徐春明老师说他们如今SwarmKit里面不依赖于外部存储的缘由。由于当时测试的Docker依赖于外部的存储，最后测试的性能问题比较严重。当时他们建议用etcd，而Acttao当时用的是Zookeeper，测试时起了网络有时候运行 docker network ls，Docker就会卡掉，基本上是挂掉的状态。

在使用Weave Proxy时有两个问题一直困扰着咱们。一个是Weave网络升级，有新版本发布时，咱们可能会选择使用新版本，可是升级比较麻烦；另外一个问题是网络的隔离性很差。升级时Weave Proxy要重启，重启了以后Mesos认为Docker Engine挂掉了，会把任务进行从新调度，但实际上在宿主机上的容器并无挂掉。这个问题对无状态服务影响不大，至关于有多个实例，可是对于数据库服务来讲，就会致使原先数据库服务运行着，又调度了一个新的任务，在DNS自动发现里一个域名会返回两个IP，致使了一个服务是可用的，另外一个服务不可用。

因为这个缘由，升级以前咱们把Mesos的Slave停掉，把全部Mesos管理的容器也停掉，让master从新进行任务调度，接着把Docker也停掉了，而后安装新版本的Weave，以后把Docker和slave启动。在升级的中途若是宿主机里面有数据库服务，会有一段时间服务不可用。

Weave基于子网的网络隔离灵活度不是很好。在Mesos考虑多租户，一个租户子网分配的过小，可能立刻就不够用，后续扩大子网的过程很是麻烦，若是一开始分配的子网特别大，又会形成浪费。

针对升级网络组件时遇到的问题可使用CNI来解决。网络隔离的问题能够在CNI的基础上使用Calico解决，Calico 基于 iptable 作了防火墙的规则。

在Mesos 1.0里配置CNI很简单。配置network CNI配置文件的目录以及CNI插件的目录， Mesos就能够启用CNI的功能。CNI对第三方的配置也很简单，这张图是Weave的配置，只要一个名称和一个type：weave-net。 Calico一样不复杂，基本上也是配置名称，支持CNI这个网络插件里面所需的配置。

使用Marathon启用的时候比较简单，在APP的Json文件里面配上IP adress，配一个network的name，这个名称就是以前配CNI里面的名称。而后配一些label标签，它与防火墙有关，再配一个Discover的端口，主要用做服务发现。经过这种方式，基本上就解决了前面提到的两个问题。

可是Acttao目前使用的仍然是Weave CNI，没有选择Calico方案的缘由是它的安全策略如今必须得手动配置，不能自动地和Mesos集成。若是内部使用，本身配备也是能够的，可是后来考虑本身来写一个marathon-calico，根据Marathon中的APP自动建立网络安全方面的策略。

Mesos容器存储

存储方案也和刚才的容器同样是分三个阶段的，中间阶段均是原生支持了扩展，容器Volume的扩展之后有一个阶段，以及Mesos1.0之后，直接支持Docker存储插件。以前Acttao基于GlusterFS作了GlusterFS集群，在每个S节点把集群挂载上去，容器经过Docker直接挂宿主机上面目录的功能来实现。

当Docker原生支持Volume插件之后，Acttao使用的是EMC的REX-Ray，这与其余Volume的插件功能相似，是咱们目前了解到的插件中功能最全的，支持第三方存储，好比OpenStack和一些商业存储硬件，包括EMC。

Mesos1.0之后原生提供了Docker Volume支持服务，经过EMC提供的 dvdcli 工具实现。最开始时EMC想利用这个功能为Mesos里面提供外部的存储，可是当时它基于Mesos的模块，只能支持Mesos容器，没法支持Docker容器。因此Mesos1.0之后直接把这个功能集成在Mesos核心。Mesos1.0之后，咱们把它也配上了，提供Mesos原生支持。它的配置比较简单，在slave里面安装dvdcli，而后设置一个Volume的check_point，用做恢复，在隔离上面设置好system/linux和docker/volume，基本上就能够启用功能了。

在Marathon里面使用第三方外部存储时，须要把external_volumes的feature 开启，真正使用时是在APP的json里面定义卷的时候，把volume里面的类型设置成外部的，provider设置成dvdi，由于目前只支持这一种方式，后面使用Docker Volume Plugin的名称，基本上就可使用了。

当前最新版本的Marathon的外部卷不能使用绝对路径，这个BUG416估计短时间内也不会获得解决。咱们把它里面dvdi provider的校验规则改一下，基本上就可使用了。前端的校验规则里面是Mesos的容器，原先设置的时候不能使用相对路径，把它改掉就能够。

个人分享就到这里，谢谢你们。