Mesos 管理 Docker 實踐
發表於 : 2017-09-17 18:28:39
https://www.xcnnews.com/kj/946178.html
為什麼選用Mesos
Mesos：
l 兩級調度框架
l 適合各種場景應用：長期運行服務、大數據、定時任務
l 混合部署
l 專註調度，在其之上按需構建PaaS
l 黃金搭檔Docker
l 與原生Swarm相比，Swarm尚不夠成熟，且無法與global macvlan共存
l 與K8S對比，實驗過發現 K8S 比較複雜，發展迅猛,版本更新迭代很快，需要投入的人力成本更多
l Mesos是一種底層級、久經沙場的調度器,在規模上，只有 Mesos已經證明了支持成百上千個節點的大型系統。
基於MESOS+MARATHON （MM）
的平台實現
功能框架：
使用 Mesos 管理 Docker 實踐
各組件描述：
l Mesos 僅負責分散式集群資源調配
l Marathon 做任務調度，資源轉移
l Zookeeper 負責Mesos-Master的選舉，Docker全局網路信息的存儲
l Haproxy/Nginx 進行服務的負載，引流
l Bamboo 負責服務的發現，通過與 Marathon Event事件對接，實時更新 Haproxy/Nginx 的配置並 reload。
組件版本：
l Mesos 1.0.0
l Marathon1.1.2
l Docker1.12
l Zookeeper3.4.5
l Haproxy1.5.14
l Bamboo0.2.20
l Nginx1.10.3
基礎鏡像篇
Docker 推崇一容器一服務，但是這對於大部分的企業並不適合，所以我們在鏡像中加入了如下主要進程:
1.Crontab
2.ssh
3.listener (supervisor event listener, 自定義的腳本，用來監聽 supervisor 發出的事件，如進程掛掉告警)
4.Scribe(輕量日誌收集)
並統一由 supervisor 管理。
另外，由於容器內部使用 free 等命令看到的都是宿主機的信息。
所以採用了lxcfs 的方案，分為三步：
1.宿主機安裝 lxcfs-2.0.3-1.1.el7.centos.x86_64.rpm，然後啟動 lxcfs 服務
2.容器內安裝 yum install procps
3.容器啟動時掛載 –volumns /var/lib/lxcfs/proc/:/docker/proc/
這樣使用 free 等命令就能看到容器本身CPU內存的使用情況了。
網路篇
網路一直是容器這塊的一大痛點，主要是容器間的跨主機通信。要麼架構複雜難以運維，要麼是性能損耗過多，主要是通過 iptables轉發、維護路由表、隧道（overlay）、大二層等方式實現。
市面上流行的方案有：
OpenVSwitch：實現簡單，但配置較為麻煩
Calico：基於BGP協議，完全通過三層路由實現，依賴 iptables
Flannel：主機間通過udp或者vxlan實現跨主機間的通信。每個主機一個子網，靈活性不足
Weave：差評
Overlay原生：基於VXLAN 實現，性能表現不佳
Macvlan：性能最優方案，基於二層隔離，所以需要二層路由器支持。
本文將介紹的是 Macvlan 方案
Macvlan，性能方面僅次於 host 模式，容器網路和物理網路完全打通。
性能排行：Host ≈ Macvlan > Calico > Flannel > Weave
附一張網路上的性能對比圖
使用 Mesos 管理 Docker 實踐
Docker 在 1.9 之後，支持定義遠端 storage 用於全局網路信息的存儲，而 docker 本身的macvlan 僅支持單台主機容器間通信，如 –driver macvlan 創建的網路 scope 是 「Local」 的，所以需要修改 docker 源碼，讓網路信息存入遠端存儲以便 IPAM。
(修改的源碼地址https://github.com/docker/libnetwork/pull/1196/files#diff-8da755307a1fe6cc4fbae651dcb29effL8)
修改完成後，重新編譯打包安裝 docker。
(宿主機上的 docker 啟動命令如下：#/usr/bin/dockerd –insecure-registry 10.24.247.22:5000 –cluster-store=zk://10.43.1.194:2181 –cluster-advertise=eno2:2376 -H unix:///var/run/docker.sock -H tcp://0.0.0.0:4243)
PS：cluster store 使用的 zookeeper
開始創建 Macvlan：
#docker network create -d macvlan –subnet=10.24.252.0/24 –gateway=10.24.252.254 -o parent=eth3.607 mac_net
10.24.252.0/24 網段需要提前在交換機上配置好規則，也就是前面所說的依賴二層交換機。
這個例子就是單獨劃分了 252 網段專門給容器使用，eth3是第四塊物理網卡，607為vlan的tag，可針對不同情況做改變。這樣你就會發現，創建出來的容器網路 mac_net 的 scope是 global 的。並且 mac_net 這個網路已經自動同步到了其他宿主機。
在不同主機上創建容器:
# docker run -itd –name test1 –net=mac_net centos7:base
# docker run -itd –name test2 –net=mac_net centos7:base
容器 test1 與 test2 均處於 10.24.252.0/24 網段中，並且能互通。
PS: 在使用 mesos + marathon 做調度時，是由上層的 marathon 來完成傳遞 docker run 任務
Mesos + Marathon + ZK集群搭建篇
Mesos分為 mesos-master（管理節點） 與 mesos-slave（計算節點）, 官方建議是至少3台mesos-master, Marathon能確保所有docker進程啟動運行，如果某個進程崩潰，Marathon會重新啟動同樣的進程，以確保每個配置運行一個實例，並直接簡單提供好的REST API用來管理容器。這裡就不做安裝步驟的複述了，具體可參見官方文檔。
附 Mesos 結構圖:
使用 Mesos 管理 Docker 實踐
Ps:需要注意的是在 master 節點的 /etc/mesos-master/quorum 配置里的數字要大於安裝的master節點的總數的0.5倍。
服務發現自動註冊篇
（Bamboo+Haproxy/Nginx）
簡而言之，Bamboo 是一個專門針對 Mesos + Marathon 自動動態生成 Haproxy 配置文件並執行 reload 的一個 web daemon。源碼僅幾千行（Golang）。
原理：
監聽 Marathon 的事件介面，Marathon 的Event介面開啟后，所有發生的事件都會從這個介面通知出來。Bamboo 通過監聽這個介面，實現動態的更新 Haproxy 配置並 reload。
原生的機制是：只要接收到新的事件，就去獲取 /v2/apps 介面下所有應用及應用內的容器IP，埠等信息，與當前的 haproxy.conf 比對，若有不同，就去更新配置並 reload。否則不動Haproxy。會有一種情況，在擴容應用時，marathon尚未完全啟動所有容器，haproxy的配置就已經被更新。我做的改進是，分析事件內容，根據事件內容再去決定是否更新 haproxy。並且把 haproxy.conf 拆分開來，一個應用一個配置，如haproxy.app.conf。根據具體應用的改變去更新，以此保證在 reload 時不會影響到所有應用。
了解Bamboo 的源碼后，再去做更多的改進就會變得很簡單，所以加入了 bamboo 對nginx的支持。而nginx 是支持熱更新 upstream 的，使用 consul + upsync 方案，我們只用讓bamboo去動態更改 consul 里的配置就好啦！
使用 Mesos 管理 Docker 實踐
(原生項目鏈接https://github.com/QubitProducts/bamboo)
還有日誌收集、容器監控(cadvisor)這裡就不做詳細描述了。
為什麼選用Mesos
Mesos：
l 兩級調度框架
l 適合各種場景應用：長期運行服務、大數據、定時任務
l 混合部署
l 專註調度，在其之上按需構建PaaS
l 黃金搭檔Docker
l 與原生Swarm相比，Swarm尚不夠成熟，且無法與global macvlan共存
l 與K8S對比，實驗過發現 K8S 比較複雜，發展迅猛,版本更新迭代很快，需要投入的人力成本更多
l Mesos是一種底層級、久經沙場的調度器,在規模上，只有 Mesos已經證明了支持成百上千個節點的大型系統。
基於MESOS+MARATHON （MM）
的平台實現
功能框架：
使用 Mesos 管理 Docker 實踐
各組件描述：
l Mesos 僅負責分散式集群資源調配
l Marathon 做任務調度，資源轉移
l Zookeeper 負責Mesos-Master的選舉，Docker全局網路信息的存儲
l Haproxy/Nginx 進行服務的負載，引流
l Bamboo 負責服務的發現，通過與 Marathon Event事件對接，實時更新 Haproxy/Nginx 的配置並 reload。
組件版本：
l Mesos 1.0.0
l Marathon1.1.2
l Docker1.12
l Zookeeper3.4.5
l Haproxy1.5.14
l Bamboo0.2.20
l Nginx1.10.3
基礎鏡像篇
Docker 推崇一容器一服務，但是這對於大部分的企業並不適合，所以我們在鏡像中加入了如下主要進程:
1.Crontab
2.ssh
3.listener (supervisor event listener, 自定義的腳本，用來監聽 supervisor 發出的事件，如進程掛掉告警)
4.Scribe(輕量日誌收集)
並統一由 supervisor 管理。
另外，由於容器內部使用 free 等命令看到的都是宿主機的信息。
所以採用了lxcfs 的方案，分為三步：
1.宿主機安裝 lxcfs-2.0.3-1.1.el7.centos.x86_64.rpm，然後啟動 lxcfs 服務
2.容器內安裝 yum install procps
3.容器啟動時掛載 –volumns /var/lib/lxcfs/proc/:/docker/proc/
這樣使用 free 等命令就能看到容器本身CPU內存的使用情況了。
網路篇
網路一直是容器這塊的一大痛點，主要是容器間的跨主機通信。要麼架構複雜難以運維，要麼是性能損耗過多，主要是通過 iptables轉發、維護路由表、隧道（overlay）、大二層等方式實現。
市面上流行的方案有：
OpenVSwitch：實現簡單，但配置較為麻煩
Calico：基於BGP協議，完全通過三層路由實現，依賴 iptables
Flannel：主機間通過udp或者vxlan實現跨主機間的通信。每個主機一個子網，靈活性不足
Weave：差評
Overlay原生：基於VXLAN 實現，性能表現不佳
Macvlan：性能最優方案，基於二層隔離，所以需要二層路由器支持。
本文將介紹的是 Macvlan 方案
Macvlan，性能方面僅次於 host 模式，容器網路和物理網路完全打通。
性能排行：Host ≈ Macvlan > Calico > Flannel > Weave
附一張網路上的性能對比圖
使用 Mesos 管理 Docker 實踐
Docker 在 1.9 之後，支持定義遠端 storage 用於全局網路信息的存儲，而 docker 本身的macvlan 僅支持單台主機容器間通信，如 –driver macvlan 創建的網路 scope 是 「Local」 的，所以需要修改 docker 源碼，讓網路信息存入遠端存儲以便 IPAM。
(修改的源碼地址https://github.com/docker/libnetwork/pull/1196/files#diff-8da755307a1fe6cc4fbae651dcb29effL8)
修改完成後，重新編譯打包安裝 docker。
(宿主機上的 docker 啟動命令如下：#/usr/bin/dockerd –insecure-registry 10.24.247.22:5000 –cluster-store=zk://10.43.1.194:2181 –cluster-advertise=eno2:2376 -H unix:///var/run/docker.sock -H tcp://0.0.0.0:4243)
PS：cluster store 使用的 zookeeper
開始創建 Macvlan：
#docker network create -d macvlan –subnet=10.24.252.0/24 –gateway=10.24.252.254 -o parent=eth3.607 mac_net
10.24.252.0/24 網段需要提前在交換機上配置好規則，也就是前面所說的依賴二層交換機。
這個例子就是單獨劃分了 252 網段專門給容器使用，eth3是第四塊物理網卡，607為vlan的tag，可針對不同情況做改變。這樣你就會發現，創建出來的容器網路 mac_net 的 scope是 global 的。並且 mac_net 這個網路已經自動同步到了其他宿主機。
在不同主機上創建容器:
# docker run -itd –name test1 –net=mac_net centos7:base
# docker run -itd –name test2 –net=mac_net centos7:base
容器 test1 與 test2 均處於 10.24.252.0/24 網段中，並且能互通。
PS: 在使用 mesos + marathon 做調度時，是由上層的 marathon 來完成傳遞 docker run 任務
Mesos + Marathon + ZK集群搭建篇
Mesos分為 mesos-master（管理節點） 與 mesos-slave（計算節點）, 官方建議是至少3台mesos-master, Marathon能確保所有docker進程啟動運行，如果某個進程崩潰，Marathon會重新啟動同樣的進程，以確保每個配置運行一個實例，並直接簡單提供好的REST API用來管理容器。這裡就不做安裝步驟的複述了，具體可參見官方文檔。
附 Mesos 結構圖:
使用 Mesos 管理 Docker 實踐
Ps:需要注意的是在 master 節點的 /etc/mesos-master/quorum 配置里的數字要大於安裝的master節點的總數的0.5倍。
服務發現自動註冊篇
（Bamboo+Haproxy/Nginx）
簡而言之，Bamboo 是一個專門針對 Mesos + Marathon 自動動態生成 Haproxy 配置文件並執行 reload 的一個 web daemon。源碼僅幾千行（Golang）。
原理：
監聽 Marathon 的事件介面，Marathon 的Event介面開啟后，所有發生的事件都會從這個介面通知出來。Bamboo 通過監聽這個介面，實現動態的更新 Haproxy 配置並 reload。
原生的機制是：只要接收到新的事件，就去獲取 /v2/apps 介面下所有應用及應用內的容器IP，埠等信息，與當前的 haproxy.conf 比對，若有不同，就去更新配置並 reload。否則不動Haproxy。會有一種情況，在擴容應用時，marathon尚未完全啟動所有容器，haproxy的配置就已經被更新。我做的改進是，分析事件內容，根據事件內容再去決定是否更新 haproxy。並且把 haproxy.conf 拆分開來，一個應用一個配置，如haproxy.app.conf。根據具體應用的改變去更新，以此保證在 reload 時不會影響到所有應用。
了解Bamboo 的源碼后，再去做更多的改進就會變得很簡單，所以加入了 bamboo 對nginx的支持。而nginx 是支持熱更新 upstream 的，使用 consul + upsync 方案，我們只用讓bamboo去動態更改 consul 里的配置就好啦！
使用 Mesos 管理 Docker 實踐
(原生項目鏈接https://github.com/QubitProducts/bamboo)
還有日誌收集、容器監控(cadvisor)這裡就不做詳細描述了。