◐
为什么选用Mesos
Mesos：
l 两级调度框架
l 适合各种场景应用：长期运行服务、大数据、定时任务
l 混合部署
l 专注调度，在其之上按需构建PaaS
l 黄金搭档Docker
l 与原生Swarm相比，Swarm尚不够成熟，且无法与global macvlan共存
l 与K8S对比，实验过发现 K8S 比较复杂，发展迅猛,版本更新迭代很快，需要投入的人力成本更多
l Mesos是一种底层级、久经沙场的调度器,在规模上，只有 Mesos已经证明了支持成百上千个节点的大型系统。
基于MESOS+MARATHON （MM）
的平台实现
功能框架：
各组件描述：
l Mesos 仅负责分布式集群资源调配
l Marathon 做任务调度，资源转移
l Zookeeper 负责Mesos-Master的选举，Docker全局网络信息的存储
l Haproxy/Nginx 进行服务的负载，引流
l Bamboo 负责服务的发现，通过与 Marathon Event事件对接，实时更新 Haproxy/Nginx 的配置并 reload。
组件版本：
l Mesos 1.0.0
l Marathon1.1.2
l Docker1.12
l Zookeeper3.4.5
l Haproxy1.5.14
l Bamboo0.2.20
l Nginx1.10.3
基础镜像篇
Docker 推崇一容器一服务，但是这对于大部分的企业并不适合，所以我们在镜像中加入了如下主要进程:
1.Crontab
2.ssh
3.listener (supervisor event listener, 自定义的脚本，用来监听 supervisor 发出的事件，如进程挂掉告警)
4.Scribe(轻量日志收集)
并统一由 supervisor 管理。
另外，由于容器内部使用 free 等命令看到的都是宿主机的信息。
所以采用了lxcfs 的方案，分为三步：
1.宿主机安装 lxcfs-2.0.3-1.1.el7.centos.x86_64.rpm，然后启动 lxcfs 服务
2.容器内安装 yum install procps
3.容器启动时挂载 --volumns /var/lib/lxcfs/proc/:/docker/proc/
这样使用 free 等命令就能看到容器本身CPU内存的使用情况了。
网络篇
网络一直是容器这块的一大痛点，主要是容器间的跨主机通信。要么架构复杂难以运维，要么是性能损耗过多，主要是通过 iptables转发、维护路由表、隧道（overlay）、大二层等方式实现。
市面上流行的方案有：
OpenVSwitch：实现简单，但配置较为麻烦
Calico：基于BGP协议，完全通过三层路由实现，依赖 iptables
Flannel：主机间通过udp或者vxlan实现跨主机间的通信。每个主机一个子网，灵活性不足
Weave：差评
Overlay原生：基于VXLAN 实现，性能表现不佳
Macvlan：性能最优方案，基于二层隔离，所以需要二层路由器支持。
本文将介绍的是 Macvlan 方案
Macvlan，性能方面仅次于 host 模式，容器网络和物理网络完全打通。
性能排行：Host ≈ Macvlan > Calico > Flannel > Weave
附一张网络上的性能对比图
Docker 在 1.9 之后，支持定义远端 storage 用于全局网络信息的存储，而 docker 本身的macvlan 仅支持单台主机容器间通信，如 --driver macvlan 创建的网络 scope 是 “Local” 的，所以需要修改 docker 源码，让网络信息存入远端存储以便 IPAM。
(修改的源码地址https://github.com/docker/libnetwork/pull/1196/files#diff-8da755307a1fe6cc4fbae651dcb29effL8)
修改完成后，重新编译打包安装 docker。
(宿主机上的 docker 启动命令如下：#/usr/bin/dockerd --insecure-registry 10.24.247.22:5000 --cluster-store=zk://10.43.1.194:2181 --cluster-advertise=eno2:2376 -H unix:///var/run/docker.sock -H tcp://0.0.0.0:4243)
PS：cluster store 使用的 zookeeper
开始创建 Macvlan：
#docker network create -d macvlan --subnet=10.24.252.0/24 --gateway=10.24.252.254 -o parent=eth3.607 mac_net
10.24.252.0/24 网段需要提前在交换机上配置好规则，也就是前面所说的依赖二层交换机。
这个例子就是单独划分了 252 网段专门给容器使用，eth3是第四块物理网卡，607为vlan的tag，可针对不同情况做改变。这样你就会发现，创建出来的容器网络 mac_net 的 scope是 global 的。并且 mac_net 这个网络已经自动同步到了其他宿主机。
在不同主机上创建容器:
# docker run -itd --name test1 --net=mac_net centos7:base
# docker run -itd --name test2 --net=mac_net centos7:base
容器 test1 与 test2 均处于 10.24.252.0/24 网段中，并且能互通。
PS: 在使用 mesos + marathon 做调度时，是由上层的 marathon 来完成传递 docker run 任务
Mesos + Marathon + ZK集群搭建篇
Mesos分为 mesos-master（管理节点） 与 mesos-slave（计算节点）, 官方建议是至少3台mesos-master, Marathon能确保所有docker进程启动运行，如果某个进程崩溃，Marathon会重新启动同样的进程，以确保每个配置运行一个实例，并直接简单提供好的REST API用来管理容器。这里就不做安装步骤的复述了，具体可参见官方文档。
附 Mesos 结构图:
Ps:需要注意的是在 master 节点的 /etc/mesos-master/quorum 配置里的数字要大于安装的master节点的总数的0.5倍。
服务发现自动注册篇
（Bamboo+Haproxy/Nginx）
简而言之，Bamboo 是一个专门针对 Mesos + Marathon 自动动态生成 Haproxy 配置文件并执行 reload 的一个 web daemon。源码仅几千行（Golang）。
原理：
监听 Marathon 的事件接口，Marathon 的Event接口开启后，所有发生的事件都会从这个接口通知出来。Bamboo 通过监听这个接口，实现动态的更新 Haproxy 配置并 reload。
原生的机制是：只要接收到新的事件，就去获取 /v2/apps 接口下所有应用及应用内的容器IP，端口等信息，与当前的 haproxy.conf 比对，若有不同，就去更新配置并 reload。否则不动Haproxy。会有一种情况，在扩容应用时，marathon尚未完全启动所有容器，haproxy的配置就已经被更新。我做的改进是，分析事件内容，根据事件内容再去决定是否更新 haproxy。并且把 haproxy.conf 拆分开来，一个应用一个配置，如haproxy.app.conf。根据具体应用的改变去更新，以此保证在 reload 时不会影响到所有应用。
了解Bamboo 的源码后，再去做更多的改进就会变得很简单，所以加入了 bamboo 对nginx的支持。而nginx 是支持热更新 upstream 的，使用 consul + upsync 方案，我们只用让bamboo去动态更改 consul 里的配置就好啦！
(原生项目链接https://github.com/QubitProducts/bamboo)
还有日志收集、容器监控(cadvisor)这里就不做详细描述了。
返回搜狐，查看更多
责任编辑：
