基於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