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

本文主要是介绍从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的容器，原先设置的时候不能使用相对路径，把它改掉就可以。
   我的分享就到这里，谢谢大家。
  
         

查看原文：http://www.zoues.com/2016/10/26/%e4%bb%8e0-25%e5%88%b01-0%ef%bc%8c%e4%b8%ad%e5%b0%8f%e4%bc%81%e4%b8%9amesos%e7%bd%91%e7%bb%9c%e5%92%8c%e5%ad%98%e5%82%a8%e7%9a%84%e5%a1%ab%e5%9d%91%e5%ae%9e%e8%b7%b5/