从 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 的容器，原先设置的时候不能使用相对路径，把它改掉就可以。

我的分享就到这里，谢谢大家。