基於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 {
     [e-mail]
   }
   notification_email_from [e-mail]
   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