基于marathon-lb的服务自发现与负载均衡

参考文档：

1. Marathon-lb介绍：https://docs.mesosphere.com/1.9/networking/marathon-lb/
2. 参考：http://www.cnblogs.com/kevingrace/p/6845980.html
3. 基于脚本实现服务自发现与负载均衡（供参考，marathon-lb以前的方案）：

   http://dockone.io/article/439

   https://github.com/draculavlad/SetUpMesosphereOnCentos7WithServiceDiscovery/

 本文主要基于marathon-lb实现mesos+marathon平台的的服务自发现与负载均衡。

一．环境

1. 环境说明

基于《基于zookeeper+mesos+marathon的docker集群管理平台》的环境，不一样处：

1. 自发现与负载均衡服务由镜像marathon-lb生成的容器完成，下发到任意1台salve节点；
2. 全部salve节点安装keepalived服务作服务的高可用，vip：10.11.5.145。 

二．部署marathon-lb

1. 准备marathon-lb镜像

#在3个slave节点提早准备镜像，以节省容器部署时间
[root@slave-node1 ~]# docker pull mesosphere/marathon-lb
[root@slave-node1 ~]# docker images

2. 拓扑编写marathon-lb的json文件

#在任意marathon master节点上编写关于marathon-lb的json文件
[root@master-node1 ~]# vim marathon-lb.json

#”network”采用HOST模式，与宿主机共享namespace;
#”args”参数将3个marathon master节点的ip:8080都带上，即marahon的api接口地址，由于不肯定marathon下发marathon-lb容器时，会下发到哪一台宿主机；
#”group”参数为”external”，能够定义多个不一样的”group”（即不一样的marathon-lb），针对不一样的应用能够绑定到不一样的”group”；
#请注意json文件的格式，如标点符号等，marathon web下的”JSON Mode”框有检查语法正确与否的功能。
{
  "id":"marathon-lb",
  "cpus": 1,
  "mem": 128,
  "instances": 1,
  "constraints": [["hostname", "UNIQUE"]],
  "container": {
  "type":"DOCKER",
  "docker": {
     "image": "mesosphere/marathon-lb",
     "privileged": true,
     "network": "HOST"
    }
  },
   "args": ["sse", "-m", "http://10.11.4.156:8080", "-m", "http://10.11.4.157:8080", "-m", "http://10.11.4.158:8080", "--group", "external"]
}

3. 下发marathon-lb容器

1）方式1：经过curl调用json配置

#调用保存有json文件的maste节点8080端口下的json文件，即调用marathon的api
[root@master-node1 ~]# curl -X POST http://10.11.4.156:8080/v2/apps -d@/root/marathon-lb.json -H "Content-type:application/json"

2）方式2：经过marathon web下发json配置

4. 查看marathon-lb

1）marathon web

marathon-lb做为一种长服务，已经下发，运行正常，以下：

marathon-lb已下发到slave节点10.11.4.146:31187，以下：

2）mesos web

mesos active tasks中显示marathon-lb任务下发成功，以下：

5. 查看haproxy

1）设置iptables

#marathon-lb生成的haproxy容器映射到宿主机的tcp 9090端口，能够在相应宿主机经过”netstat -tunlp | grep haproxy”查看；
#须要在全部的宿主机，即slave节点放行tcp 9090端口，由于在没有指定特定主机的时候（在slave启动参数中设置机器属性 --attributes=VALUE），经过marathon下发的marathon-lb容器是随机下发到任意slave节点的；
#不重启iptables，若是重启则docker daemon也须要重启，不然iptables相关的docker的forward规则会丢失；或者在没有容器的状况下提早放行相应端口再作容器相关操做
[root@slave-node1 ~]# iptables -I INPUT -m state --state NEW -m tcp -p tcp --dport 9090 -j ACCEPT

2）haproxy监控页面

浏览器查看：http://10.11.4.146:9090/haproxy?stats

另外还有一些haproxy监控页面（ip地址是宿主机，即相应slave节点的ip），以下：

• 监控页面：http://ip:9090/haproxy?stats
• csv格式的状态监控：http://ip:9090/haproxy?stats;csv
• 健康检查（注意下划线）：http://ip:9090/_haproxy_health_check
• haproxy配置获取（注意下划线）：http://ip:9090/_haproxy_getconfig
• haproxy的pid（注意下划线）：http://ip:9090/_haproxy_getpids

三．验证自动发现与负载均衡

经过部署nginx服务能够验证自动发现与负载均衡两项功能。

1. 编写生成nginx服务的json文件

#在任意marathon master节点上编写json文件
[root@master-node1 ~]# vim marathon-nginx.json

#“labels”中的“HAPROXY_GROUP”，与相关的marathon-lb绑定便可，“group”在下发marathon-lb容器时已经定义；
#“labels”中"HAPROXY_0_VHOST"主要起标签做用；对于web服务能够加上VHOST标签，让marathon-lb设置WEB虚拟主机；标签名字自定义，目的是为了便于区别应用容器，通常能够用业务域名来描述标签；
#"instances"，实例数；
#"healthChecks"，对应示例健康状态检测点；
#"portMappings"中的"containerPort"是容器应用端口；"hostPort"是映射的宿主机的端口（设置为”0”即随机）；"servicePort"是marathon-lb配置的haproxy代理端口（设置为”0”即随机），设置"servicePort"对一组实例服务很是有用；
{
  "id":"web",
  "labels": {
     "HAPROXY_GROUP":"external",
     "HAPROXY_0_VHOST":"web.nginx.com"
  },
  "cpus":0.2,
  "mem":20.0,
  "instances": 2,
  "healthChecks": [{ "path": "/" }],
  "container": {
    "type":"DOCKER",
    "docker": {
     "image": "nginx",
     "network": "BRIDGE",
     "portMappings":[{"containerPort":80,"hostPort":0,"servicePort":0,"protocol":"tcp"}]
    }
  }
}

2. 下发nginx服务

#采用上述方式1下发服务便可；
#nginx镜像已经提早准备
[root@master-node1 ~]# curl -X POST http://10.11.4.156:8080/v2/apps -d@/root/marathon-nginx.json -H "Content-type:application/json"

3. 验证

1）查看marathon&mesoso ui

（1）marathon ui显示web服务已是"Running"状态，且服务名后带标签；

（2）点击查看服务的具体信息，"Instances"标签中显示了2个instance容器部署的slave节点与映射的端口信息（能够在具体的slave节点经过"docker ps"命令查看），同时健康检查状态正常；

（3） "Configuration"标签中有展现服务的具体配置信息，同json文件，关注标红框的"servicePort"是10002，此服务端口是随机分配的，可经过marathon-lb所在节点的ip+port的方式访问服务，而不是访问单独的某个instance节点提供的服务；

（4）mesos ui展现显示web服务的两个instance任务已经下发。

2）访问容器instance提供的服务

#能够先将2个nginx instance的web页面提早修改；
#如marathon ui展现，1个nginx容器在slave节点10.11.4.146:31005
#在10.11.4.146，即slave-node1节点编写index.html文件，使用”docker cp”将文件覆盖对应容器的默认web站点目录”/usr/share/nginx/html”下的index.html文件
[root@slave-node1 ~]# echo "This is Nginx Server: 10.11.4.146:31005" >> index.html
[root@slave-node1 ~]# docker cp /root/index.html 2c7448e2d185:/usr/share/nginx/html

#如marathon ui展现，另1个nginx容器在slave节点10.11.4.147:31071；
#10.11.4.147，即slave-node2节点
[root@slave-node2 ~]# echo "This is Nginx Server: 10.11.4.147:31071" >> index.html
[root@slave-node2 ~]# docker cp /root/index.html 11060abfad4f:/usr/share/nginx/html

3）访问haproxy提供的服务

（1）访问marathon-lb所在slave节点的10002端口（在marathon ui服务的configuration能够查询分配的servicePort）；

URL：http://10.11.4.146:10002

PS：10002端口须要在相应节点不重启iptables的状况下放行，能够执行iptables -I INPUT -m state --state NEW -m tcp -p tcp --dport 10002 -j ACCEPT

（2）查看marathon-lb haproxy的配置；

URL：http://10.11.4.146:9090/_haproxy_getconfig

PS：或者登录到marathon-lb容器中查看haproxy.cfg文件（效果一致）。

（3）查看marathon-lb haproxy的状态页；

URL：http://10.11.4.146:9090/haproxy?stats

四．keepalived高可用配置

对于marathon-lb或者其后端的real-server来讲，对外提供的服务都依靠marathon-lb容器所在slave节点自己的ip，虽然marathon能长久保持服务在线，但对外提供服务的ip的变化仍是须要高可用的设置，这里采用keepalived实现，vip：10.11.4.145。

Keepalived服务须要安装配置在全部marathon-lb可能下发到的slave节点。

1. 安装keepalived

Keepalived服务须要安装配置在全部marathon-lb可能下发到的slave节点。

keepalived版本：keepalived-1.3.6

具体的安装步骤请见：http://www.cnblogs.com/netonline/p/7598744.html

PS：注意各keepalived节点之间通告采用组播，iptables须要放行组播或vrrp相关协议。

2. keepalived配置文件

#各slave节点的keepalived配置文件根据状况作微小调整
[root@slave-node1 ~]# vim /usr/local/keepalived/etc/keepalived/keepalived.conf

! Configuration File for keepalived

global_defs {
   notification_email {
     root@localhost.local
   }
   notification_email_from root@localhost.local
   smtp_server 10.11.4.146
   smtp_connect_timeout 30
   router_id MARATHON_DEVEL
}

vrrp_script chk_marathonlb { script "/usr/local/keepalived/etc/chk_marathonlb.sh"
    interval 1
    weight 2          //脚本检测返回值为”0”时，权重上升
    rise 1 }

vrrp_instance VI_1 {
    state BACKUP
    interface br0
    virtual_router_id 201
    priority 101
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 987654
    }
    virtual_ipaddress {
        10.11.4.145
    }
 track_script { chk_marathonlb }
}

3. marathon-lb检测脚本

#根据配置文件中的配置设定检测脚本
[root@slave-node1 ~]# touch /usr/local/keepalived/etc/chk_marathonlb.sh
[root@slave-node1 ~]# chmod +x /usr/local/keepalived/etc/chk_marathonlb.sh
[root@slave-node1 ~]# vim /usr/local/keepalived/etc/chk_marathonlb.sh

#!/bin/bash
# check if thers is a matathon-lb container running, then this is a keepalived master.
# 2017-09-18 v0.1 

MARATHONLB_LOG="/tmp/marathon-lb.log"

MARATHONLB=`netstat -tunlp | grep "haproxy" | grep ":80" | awk '{print $4}' | awk  'BEGIN{FS=":"} {print $2}'`

#检测marathon-lb服务的80端口，若存在则返回”0”，不存在返回”1”；
#记录日志，非必须项
if [ ${MARATHONLB} -eq 80 ]; then
     echo -e "`date +%F\ %T`: Matathon-lb is here, exit!\n" >> $MARATHONLB_LOG
     exit 0
         
else
     echo -e "`date +%F\ %T`: Matathon-lb is not here, the keepalived weight will be downgraded." >> $MARATHONLB_LOG
     exit 1
fi

4. 验证

1）启动并查看vip

#验证过程当中，marathon-lb所在的slave1节点宕机，marathon为了保持服务，将marathon-lb从新下发到在salve2节点
[root@slave-node2 ~]# systemctl daemon-reload
[root@slave-node2 ~]# systemctl restart keepalived
[root@slave-node2 ~]# ip a show br0

2）访问服务

#web服务下的两个instance都被重置过，这里修改新instance容器的index.html文件
[root@slave-node2 ~]# echo "This is Nginx Server: 10.11.4.147:31288" > index.html
[root@slave-node2 ~]# docker cp /root/index.html 9489b51370fd:/usr/share/nginx/html
[root@slave-node2 ~]# echo "This is Nginx Server: 10.11.4.147:31646" > index.html
[root@slave-node2 ~]# docker cp /root/index.html 2aee995a6ce7:/usr/share/nginx/html

（1）访问vip的10002端口；

URL：http://10.11.4.145:10002

（2）经过vip访问marathon-lb状态页。

URL：http://10.11.4.145:9090/haproxy?stats