参考文档:

Mesos-dns 和 Marathon-lb
是mesosphere
官网提供的两种服务发现和负载均衡工具。官方的文档主要针对DCOS,针对其它系统的相关中文文档不多,下面是我在Centos7上的安装说明和使用总结。

  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/

1. Mesos服务发现与负载均衡

默认情况下,mesos marathon会把app发布到随机节点的随机端口上,当mesos slaves和app越来越多的时候,想查找某组app就变得困难。

mesos提供了两个工具:mesos-dns和marathon-lb。mesos-dns是一个服务发现工具,marathon-lb不仅是服务发现工具,还是负载均衡工具。

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

2. mesos-dns

Mesos-dns是 mesos 服务发现工具,能查找app的Ip,端口号以及master,leader等信息。

一.环境

2.1 安装

从下述地址下载mesos-dns二进制文件:

https://github.com/mesosphere/mesos-dns/releases

重命名为mesos-dns

chmod
+x mesos-dns

按照官方文档编写config.json,填入zk、master等相关信息 

 

1. 环境说明

图片 1

基于《基于zookeeper+mesos+marathon的docker集群管理平台》的环境,不同处:

  1. 自发现与负载均衡服务由镜像marathon-lb生成的容器完成,下发到任意1台salve节点;
  1. 所有salve节点安装keepalived服务做服务的高可用,vip:10.11.5.145。 

2.2 启动

二.部署marathon-lb

2.2.1 命令行方式

mesos-dns -config
config.json

1. 准备marathon-lb镜像

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

图片 2

2.2.2 也可以用marathon部署

#mesos-dns.json

{
“id”:
“mesos-dns”,
“cpus”: 0.5,
“mem”: 128.0,
“instances”: 3,
“constraints”:
[[“hostname”, “UNIQUE”]],
“cmd”:
“/opt/mesos-dns/mesos-dns -config /opt/mesos-dns/config.json”
}

#向marathon发送部署内容

curl -i -H ‘Content-Type:
application/json’ 172.31.17.71:8080/v2/apps -d@mesos-dns.json

图片 3

图中的mesos-dns是通过marathon部署的mesos-dns,共两个实例。

 

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"]
}

2.3 使用方法

注:slave4是安装了mesos-dns的主机名

3. 下发marathon-lb容器

2.3.1 查找app的ip

dig
test-app.marathon.mesos +short @slave4

172.17.0.2

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.3.2 查找app所在节点的IP

dig
test-app.marathon.slave.mesos +short @slave4

172.31.17.33
172.31.17.31
172.31.17.32

2)方式2:通过marathon web下发json配置

图片 4

2.3.3 查找app服务端口号

dig SRV
_test-app._tcp.marathon.mesos +short @slave4

0 0
31234
test-app-s3ehn-s11.marathon.slave.mesos.

0 0
31846
test-app-zfp5d-s10.marathon.slave.mesos.

0 0
31114
test-app-3xynw-s12.marathon.slave.mesos.

 

4. 查看marathon-lb

3. marathon-lb

Marathon-lb既是一个服务发现工具,也是负载均衡工具,它集成了haproxy,自动获取各个app的信息,为每一组app生成haproxy配置,通过servicePort或者web虚拟主机提供服务。

要使用marathonn-lb,每组app必须设置HAPROXY_GROUP标签。

Marathon-lb运行时绑定在各组app定义的服务端口(servicePort,如果app不定义servicePort,marathon会随机分配端口号)上,可以通过marathon-lb所在节点的相关服务端口访问各组app。

例如:marathon-lb部署在slave5,test-app
部署在slave1,test-app 的servicePort是10004,那么可以在slave5的
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后通过虚拟主机名来访问。

 

1)marathon web

marathon-lb作为一种长服务,已经下发,运行正常,如下:

图片 5

marathon-lb已下发到slave节点10.11.4.146:31187,如下:

图片 6

3.1 安装

#下载marathon-lb镜像

docker
pull docker.io/mesosphere/marathon-lb

可以通过docker run运行,也可以通过marathon部署到mesos集群里。

 

2)mesos web

mesos
active tasks中显示marathon-lb任务下发成功,如下:

图片 7

3.2 运行

5. 查看haproxy

3.2.1 命令行运行

docker run -d –privileged
-e PORTS=9090 –net=host docker.io/mesosphere/marathon-lb sse -m
http://master1\_ip:8080 -m http://master2\_ip:8080 -m
http://master3\_ip:8080  –group external

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

3.2.2 通过marathon部署 

{
“id”:
“marathon-lb”,
“instances”: 3,
“constraints”:
[[“hostname”, “UNIQUE”]],
“container”: {
“type”:
“DOCKER”,
“docker”: {
“image”:
“docker.io/mesosphere/marathon-lb”,
“privileged”:
true,
“network”:
“HOST”
}
},
“args”: [“sse”,
“-m”,”http://master1\_ip:8080“, “-m”,”http://master2\_ip:8080“,
“-m”,”http://master3\_ip:8080","–group“, “external”]
}

curl -i -H ‘Content-Type:
application/json’ 172.31.17.71:8080/v2/apps -d@marathon-lb.json

 

2)haproxy监控页面

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

图片 8

另外还有一些haproxy监控页面(ip地址是宿主机,即相应slave节点的ip),如下:

3.3 使用方法

下面使用marathon-lb对http服务进行服务发现和负载均衡:

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

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

3.3.1 发布app

#
先创建app的json配置信息

一定要加上HAPROXY_GROUP标签,对于web服务,可以加上VHOST标签,让marathon-lb设置WEB虚拟主机;

对于web服务,servicePort设置为0即可,marathon-lb会自动把web服务集群发布到80、443上; 

{
“id”:
“test-app”,
“labels”: {
“HAPROXY_GROUP”:”external”,
“HAPROXY_0_VHOST”:”test-app.gkkxd.com”
},
“cpus”: 0.5,
“mem”: 64.0,
“instances”: 3,
“constraints”:
[[“hostname”, “UNIQUE”]],
“container”: {
“type”:
“DOCKER”,
“docker”: {
“image”:
“httpd”,
“privileged”:
false,
“network”:
“BRIDGE”,
“portMappings”:
[
{ “containerPort”: 80,
“hostPort”: 0, “servicePort”: 0,
“protocol”: “tcp”}
]
}
}
}

#发布app

curl -i
-H ‘Content-Type: application/json’ 172.31.17.71:8080/v2/apps
-d@test-app.json

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"}]
    }
  }
}

3.3.2 访问app

先设置DNS或者hosts文件:

172.31.17.34 test-app.gkkxd.com

用浏览器通过http和https访问虚拟主机,发现服务已经启动,实际上是marathon-lb内置的haproxy对test-app的三个实例配置的web服务集群:

http://test-app.gkkxd.com

https://test-app.gkkxd.com

图片 9

对于marathon-lb,可以同时部署多台,然后用DNS轮询或者keepalived虚拟IP实现高可用。

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”状态,且服务名后带标签;

图片 10

(2)点击查看服务的具体信息,”Instances”标签中显示了2个instance容器部署的slave节点与映射的端口信息(可以在具体的slave节点通过”docker
ps”命令查看),同时健康检查状态正常;

图片 11

(3)
“Configuration”标签中有展示服务的具体配置信息,同json文件,关注标红框的”servicePort”是10002,此服务端口是随机分配的,可通过marathon-lb所在节点的ip+port的方式访问服务,而不是访问单独的某个instance节点提供的服务;

图片 12

(4)mesos
ui展示显示web服务的两个instance任务已经下发。

图片 13

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

图片 14

#如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

图片 15

3)访问haproxy提供的服务

(1)访问marathon-lb所在slave节点的10002端口(在marathon
ui服务的configuration可以查询分配的servicePort);

URL:http://10.11.4.146:10002

图片 16

图片 17

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

图片 18

PS:或者登陆到marathon-lb容器中查看haproxy.cfg文件(效果一致)。

(3)查看marathon-lb
haproxy的状态页;

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

图片 19

四.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

图片 20

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

图片 21

图片 22

(2)通过vip访问marathon-lb状态页。

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

图片 23

相关文章