docker集群——Mesos集群下的负载均衡marathon-lb

前面的章节介绍了Mesos+Zookeeper+Marathon的Docker管理平台，接下来介绍如何在该平台下构建负载均衡。

默认情况下，mesos marathon会把app发布到随机节点的随机端口上，当mesos slaves和app越来越多的时候，想查找某组app就变得困难。
mesos提供了两个工具：mesos-dns和marathon-lb，他们俩是mesosphere 官网提供的两种服务发现和负载均衡工具，其中：
mesos-dns是一个服务发现工具，marathon-lb不仅是服务发现工具，还是负载均衡工具。

marathon-lb介绍

鉴于Mesos-DNS有如下诸多缺陷：

DNS不能识别服务端口，除非使用DIG的SRV进行直接查询。大多数应用不能立即使用SRV记录
DNS没有快速容错
DNS记录有一个TTL（生存时间），并且Mesos-DNS使用池创建DNS记录，这样SRV记录会稍有滞后
DNS不能提供任何服务健康状态数据
一些应用和库不能正确的处理多个SRV记录。很多情况下查询或许是缓存过的，以及不能按照实际需要被正确的重新装载

所以现在一般不推荐使用Mesos-DNS作为服务发现工具，而是推荐使用marathon-lb，marathon-lb是可以起到与Mesos-DNS同样作用。

Marathon-lb是个基于HAProxy的快速代理和负载均衡。他能为基于TCP和HTTP协议的应用提供代理和负载均衡，此外还支持SSL、健康检查、HTTP压缩、Lua脚本等特性。

Marathon-lb通过Marathon的EventBus可以自动获取Marathon上每个应用的信息，并且能够为每组应用生成HAProxy配置。不同于通过域名机制来发现服务的Mesos-DNS，Marathon-lb是通过servicePort服务端口来发现服务外，另外，还可以通过VHOST来访问服务。

要使用marathonn-lb，每组app必须设置HAPROXY_GROUP标签。
Marathon-lb运行时绑定在各组app定义的服务端口（servicePort，如果app不定义servicePort，marathon会随机分配端口号）上，可以通过marathon-lb所在节点的相关服务端口访问各组app。比如说：marathon-lb部署在slave2，test-app 部署在slave1，test-app 的servicePort是10004，那么可以在slave2的10004端口访问到test-app提供的服务。
由于servicePort非80、443端口（80、443端口已被marathon-lb中的 haproxy独占），对于web服务来说不太方便，可以使用 haproxy虚拟主机解决这个问题：在提供web服务的app配置里增加HAPROXY_{n}_VHOST（WEB虚拟主机）标签，marathon-lb会自动把这组app的WEB集群服务发布在marathon-lb所在节点的80和443端口上，用户设置DNS后通过虚拟主机名来访问。

配置Marathon-lb

首先分别在slave-1、slave-2、slave-3节点机器上拉去marathon-lb镜像：

[root@slave-1 ~]# docker pull mesosphere/marathon-lb

[root@slave-1 ~]# docker images

REPOSITORY                         TAG                 IMAGE ID            CREATED             SIZE

docker.io/nginx                    latest              2f7f7bce8929        12 days ago         107.5 MB

docker.io/tomcat                   latest              a2fbbcebd67e        2 weeks ago         333.9 MB

docker.io/mesosphere/marathon-lb   latest              8fffa444b894        2 weeks ago         181.3 MB

编写marathon-lb的json文件：

[root@master-1 ~]# vim marathon-lb.json

{

"id": "marathon-lb",

"instances": 1,

"constraints": [["hostname", "UNIQUE"]],

"container": {"type": "DOCKER",

"docker": {

"image": "docker.io/mesosphere/marathon-lb",

"privileged": true,

"network": "HOST"

}

},

"args":["sse","-m","http://192.168.93.133:8080","-m","http://192.168.93.134:8080","-m","http://192.168.93.135:8080","--group","external"]

}

也可以通过marathon是访问界面里点击“Create Application”，在“JSON Mode”模式下，将上面marathon-lb.json文件粘贴进去：

接着编写应用的json，然后构建应用。这里以创建docker的nginx容器应用为例：

[root@master-1 ~]# vim docker_nginx.json

{

  "id":"nginx",

  "labels": {

     "HAPROXY_GROUP":"external",

     "HAPROXY_0_VHOST":"nginx.marathon.mesos"

  },

  "cpus":0.2,

  "mem":20.0,

  "instances": 2,

  "healthChecks": [{ "path": "/" }],

  "container": {

    "type":"DOCKER",

    "docker": {

     "image": "docker.io/nginx",

     "network": "BRIDGE",

     "portMappings":[{"containerPort":80,"hostPort":0,"servicePort":80,"protocol":"tcp"}]

    }

  }

}

注意几点：

一定要加上HAPROXY_GROUP标签，它填写的是marathon-lb创建时定义的组名（如上）
HAPROXY_0_VHOST是标签名，对于web服务可以加上VHOST标签，让marathon-lb设置WEB虚拟主机；这个标签名字可以随便定义，目的是为了便于区别应用容器。一般可以用业务域名来描述标签。
"instances"表示应用的实例数，一般默认是1，如果写成n，说明创建n个应用。
containerPort为80,是指容器内的端口。
hostPort是当前主机映射到contenterPort的端口，如果hostPort为0的话,则说明是随机的。
serverPort是marathon-lb需要配置的haproxy代理暴露的端口,这里设置为80，说明访问marathon-lb机器的80端口就可为访问这个应用容器的80端口。

需要记住：
　　对于web服务，servicePort设置为0即可，marathon-lb会自动把web服务集群发布到80、443上；
　　所以上面docker_nginx_json文件里的"servicePort"后面的端口可以写成0，这样后端若是有443端口开启，marathon-lb会自动分发到上面。
　　最后把域名解析到marathon-lb所在的机器ip上，访问域名时就会自动发布到后端的容器应用上。

同样我们也可以在marathon管理控制界面创建nginx容器：

应用容器创建好之后，如下，可以看到容器创建后的“Labels”标签信息，这个在应用容器繁多的情况下很有用，便于识别：

还可以在创建一组绑定marathon-lb的nginx应用容器（只需要将docker_nginx.json文件里的id改变一下，比如改成“nginx2”，然后创建这个应用）

为了试验效果，分别将下面绑定了marathon-lb的四个nginx容器的访问内容修改一下：

[root@slave-2 ~]# docker ps

CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                   NAMES

2d0117ff35d5        docker.io/nginx     "nginx -g 'daemon off"   5 minutes ago       Up 4 minutes        0.0.0.0:31112->80/tcp   mesos-7e126eca-5cc9-4dab-97a7-ee25132ae82e-S1.4899d7cc-0062-4502-afaf-3a435deefb6c

[root@slave-2 ~]# cat index.html

this is nginx - port:31112

[root@slave-2 ~]# docker cp index.html 2d0117ff35d5:/usr/share/nginx/html

其余的同理。

访问四个Nginx容器的页面：

登录marathon-lb的容器里面，查看生成的haproxy.cfg文件：

[root@slave-3 ~]# docker ps

CONTAINER ID        IMAGE                              COMMAND                  CREATED             STATUS              PORTS               NAMES

1e7967120ce4        docker.io/mesosphere/marathon-lb   "tini -g -- /marathon"   7 seconds ago       Up 6 seconds                            mesos-7e126eca-5cc9-4dab-97a7-ee25132ae82e-S2.bd0b3c6d-ff9f-470e-b617-e3f4ecd49cbb

[root@slave-3 ~]# docker exec -it 1e7967120ce4 /bin/bash

root@slave-3:/marathon-lb# cat haproxy.cfg

......

......

frontend nginx_80

  bind *:80

  mode http

  use_backend nginx_80

frontend nginx2_80

  bind *:80

  mode http

  use_backend nginx2_80

backend nginx_80

  balance roundrobin

  mode http

  option forwardfor

  http-request set-header X-Forwarded-Port %[dst_port]

  http-request add-header X-Forwarded-Proto https if { ssl_fc }

  option  httpchk GET /

  timeout check 20s

  server 192_168_93_136_31399 192.168.93.136:31399 check inter 60s fall 4

  server 192_168_93_137_31112 192.168.93.137:31112 check inter 60s fall 4

backend nginx2_80

  balance roundrobin

  mode http

  option forwardfor

  http-request set-header X-Forwarded-Port %[dst_port]

  http-request add-header X-Forwarded-Proto https if { ssl_fc }

  option  httpchk GET /

  timeout check 20s

  server 192_168_93_136_31464 192.168.93.136:31464 check inter 60s fall 4

  server 192_168_93_136_31703 192.168.93.136:31703 check inter 60s fall 4

这时候我们访问marathon-lb容器所在机器的80端口，则请求就会负载到后端的nginx机器上，不断刷新就会负载到后端不同的页面上：

可以在三个slave节点上做keepalived心跳测试，绑定一个VIP，三个节点做成一主两从，keepalived.conf里监控80端口的marathon-lb进程。当marathon-lb在哪个节点上，VIP就漂移到那个节点上，业务域名解析到VIP上，这样也就完成了一个高可用方案。

查看haproxy的监控页面：

总结几点：

docker应用容器创建时的servicePort端口设置，这个关系到使用haproxy负载后，最终的访问端口。
可以创建不同的marathon-lb容器（可以定义不同的group），然后依据这些marathon-lb创建不同业务的应用容器，以实现负载均衡。
marathon-lb容器默认会在三个slave节点中的某一个节点上创建，当所在节点出现故障或重启marathon-lb容器时，才会漂移到其他节点上，这样即实现了高可用（相当于"一主两从"），将业务玉域名解析到marathon-lb所在的节点ip上。
如果之前创建的应用容器绑定了marathon-lb，后续这个应用容器删除了，那么要记得重启marathon-lb，否则LB访问会出现故障。因为haproxy.cfg文件里还保留这个已删的应用容器的负载配置，重启marathon-lb后，haproxy.cfg文件才会更新。
为了安全考虑，最好不要将Marathon暴漏到公网上，要不定时监控Docker运行情况。此外，Mesos和Marathon启动的时候最好加认证，具体操作是：Marathon启动的时候加上--http_credentials即可，然后Mesos启动时候加上--authenticate --credentials参数，让Mesos slave 连接到Master的时候加上认证。