摘要：由于沒(méi)有了中心化的負(fù)載均衡器，集群不會(huì)因某臺(tái)機(jī)器異常而導(dǎo)致整個(gè)服務(wù)對(duì)外不可用，很好的避免了單點(diǎn)問(wèn)題，同時(shí)也帶了可擴(kuò)展性。

Mesos/Marathon 折騰久了，我們一直希望有機(jī)會(huì)深入到 Swarm 內(nèi)部一探究竟。 另外， Mesos 這一套東西雖然是久經(jīng)企業(yè)級(jí)考驗(yàn)的， 但是安裝、部署和使用相對(duì)復(fù)雜，上手有門(mén)檻。同時(shí)，在今年的 DockerCon 上，內(nèi)置了Swarm 功能的 Docker 1.12 發(fā)布。基于以上背景，數(shù)人云計(jì)劃圍繞 Docker 1.12 Swarm 開(kāi)發(fā)一版輕量級(jí)的集群管理工具，也借此與 Mesos/Marathon 對(duì)比下。目前，我們第一版數(shù)人云容器管理面板 Crane 已經(jīng)開(kāi)發(fā)完畢，過(guò)程也是磕磕絆絆，這里趁機(jī)總結(jié)幾篇技術(shù)分享。

正文開(kāi)始前先八卦一下，關(guān)注 Docker 技術(shù)的小伙伴們應(yīng)該清楚 Docker 1.12 的 Swarm mode 頗受爭(zhēng)議：首先是有人認(rèn)為 Docker 公司 Market Drive Develop，違背了 Linux 信徒恪守的哲學(xué)——一個(gè)工具只干一件事情；其次， 有人認(rèn)為 Swarm mode 的功能不及 Mesos 和 K8S，還不適合生產(chǎn)環(huán)境使用，這一點(diǎn)我倒認(rèn)為穩(wěn)定性而不是功能才是 Swarm 目前不適合生產(chǎn)環(huán)境的原因；最后， Docker 的向后兼容性不足也引來(lái)口水無(wú)數(shù)，畢竟 Docker 還在 active develop。其它的像容器網(wǎng)絡(luò)標(biāo)準(zhǔn)的爭(zhēng)議， Runc 的爭(zhēng)議這些都把 Docker 推到了風(fēng)口浪尖。當(dāng)然，不辯不明，相信 Docker 給我們提供的不止眼前這些。

我們首先從應(yīng)用編排（ Application Stack）談起，應(yīng)用編排是 Docker 1.12 引入的概念，目前還是 experimental 的功能，必須得安裝 experimental 的包才可以嘗試。除去編排 (stack), Docker 1.12 還引入了服務(wù) (service) 和任務(wù) (task) 的概念， Docker 借此重新闡述了應(yīng)用與容器 (container) 之間的關(guān)系。上述幾個(gè)概念的關(guān)系如下圖所示：

（圖片來(lái)自網(wǎng)絡(luò)）

即：一個(gè)應(yīng)用編排代表一組有依賴關(guān)系的服務(wù)，服務(wù)之間可以相互發(fā)現(xiàn)（后面詳細(xì)介紹），每個(gè)服務(wù)由多個(gè)任務(wù)組成，任務(wù)的數(shù)量可以擴(kuò)縮 (scale)，而任務(wù)則物化為一個(gè)具體的 Docker 容器及其配置。

Docker 通過(guò)擴(kuò)展名為 dab（ Distributed application bundles) 的文件來(lái)描述一個(gè)應(yīng)用編排，下圖是一個(gè)帶有兩個(gè)服務(wù)的 dab 文件例子：

這里有dab文件的詳細(xì)介紹：
https://github.com/docker/doc...

其中 Image 這里推薦使用 image@digest 而不是 image:tag，原因是為了避免這種情況 : 在集群中部署服務(wù)時(shí)， image:tag 無(wú)法保證鏡像是全局一致的，本地的 image:tag 可能與鏡像倉(cāng)庫(kù)里面的 image:tag 數(shù)據(jù)不一致，這個(gè)問(wèn)題在跨機(jī)環(huán)境中被放大。而 image@digest 這種方式通過(guò)中心化倉(cāng)庫(kù)設(shè)置全局唯一的 digest 值，避免了上述問(wèn)題。

除此之外，還有下述幾個(gè)關(guān)鍵特性值得分享：

滾動(dòng)更新：服務(wù)的鏡像更新是一個(gè)基本訴求。 Docker 可以通過(guò)關(guān)鍵詞 update-parallelism 和 update-delay 來(lái)控制并行更新的頻率。 Marathon 也提供了類似的功能。這個(gè)特性很關(guān)鍵，如果無(wú)法控制更新頻率，成百上千的鏡像拉取和任務(wù)調(diào)度會(huì)導(dǎo)致嚴(yán)重的資源波峰。 Docker 文檔還聲稱支持更新失敗回滾，嘗試了下，目前沒(méi)發(fā)現(xiàn)怎么玩，還沒(méi)來(lái)得及看底層代碼。

服務(wù)模式 (service mode): Docker 1.12 提供了兩種方式控制任務(wù)數(shù)量—— replicated 和 global，在 replicated 方式下，我們需要提供期望的任務(wù)數(shù)量， Swarm 將一直嘗試維護(hù)這個(gè)任務(wù)數(shù)；而在 global 方式下， Swarm 嘗試在每個(gè)節(jié)點(diǎn)上啟動(dòng)一個(gè)任務(wù)，這種方式特別適合向每個(gè)節(jié)點(diǎn)下發(fā) agent 的場(chǎng)景。

stop-grace-period 參數(shù)：在服務(wù)縮容時(shí)，我們比較關(guān)心容器被強(qiáng)制 kill 而帶來(lái)的事務(wù) (transaction) 問(wèn)題，配合該參數(shù) stop-grace-period( 強(qiáng)制殺死容器前的等待時(shí)間 ) 和容器內(nèi)部的退出信號(hào)監(jiān)聽(tīng)，可以達(dá)到容忍程序友好退出和快速回收資源之間的平衡。 Mesos / Marathon 也采用了類似的策略來(lái)解決這個(gè)問(wèn)題。

with-registry-auth 參數(shù)：在服務(wù)創(chuàng)建時(shí)，該參數(shù)聲明將管理節(jié)點(diǎn) (Swarm manager) 上的 registry authentication 信息帶到工作節(jié)點(diǎn) (worker node) 上，從而為工作節(jié)點(diǎn)提供從 registry 拉取鏡像的認(rèn)證信息。在 Docker 的非 Swarm 場(chǎng)景下， Docker-client 負(fù)責(zé) registry 認(rèn)證信息的管理，但在 Swarm 方式下，不再是 Docker-client 觸發(fā)鏡像拉取動(dòng)作，所以服務(wù)無(wú)法使用工作節(jié)點(diǎn)本地的 registry 認(rèn)證信息了，必須要通過(guò)上述方式從管理節(jié)點(diǎn)分發(fā)認(rèn)證信息。同時(shí)節(jié)點(diǎn)間的加密通信也保證了認(rèn)證信息傳輸?shù)陌踩浴?/p>

任務(wù)的生命周期：在容器的生命周期之上， Docker 1.12 引入了任務(wù) (task) 的生命周期。某任務(wù)下的容器異常退出時(shí)，帶有同樣任務(wù)編號(hào) (slot) 的新容器將會(huì)被嘗試啟動(dòng)。不同于容器的生命周期只囿于一臺(tái)固定主機(jī)上，任務(wù)的生命周期是與主機(jī)無(wú)關(guān)的，我們可以依此對(duì)容器的日志進(jìn)行聚合得到任務(wù)的日志。這一點(diǎn)正好是 Mesos / Marathon 所欠缺的。

重啟策略：Docker 1.12 提供了三種重啟條件 -any, none, on-failure，其中 none 指的是退出不重啟，on-failure 指的是失敗（ exit code 不是零）時(shí)重啟，而 any 指的是無(wú)論任務(wù)正常或是異常退出，都重啟。any 方式配合參數(shù)重啟間隔 (restart-delay) 可以滿足定時(shí)任務(wù)的場(chǎng)景； none 方式則可以滿足批處理任務(wù)場(chǎng)景。另外參數(shù)評(píng)估間隔 (restart-window) ＋參數(shù)嘗試次數(shù) (restart-max-attempts) 可以控制在一段時(shí)間內(nèi)的任務(wù)重啟次數(shù)，避免異常任務(wù)頻繁重啟帶來(lái)的集群資源失控。

當(dāng)然，Swarm mode 還有很多問(wèn)題亟待解決：

dab 文件的表達(dá)能力有限：當(dāng)前版本的 dab 文件只有寥寥數(shù)個(gè)關(guān)鍵詞，服務(wù) (service) 創(chuàng)建的諸多參數(shù) dab 都無(wú)法支持。在我們的實(shí)踐中，為了解決這個(gè)問(wèn)題， team 不得不二次開(kāi)發(fā)引入服務(wù)的其它參數(shù)，以期對(duì)服務(wù)的參數(shù)全量支持。

容器回收問(wèn)題：按照目前的設(shè)計(jì)，只要服務(wù) (service) 還在，退出的容器是不會(huì)被自動(dòng)回收掉的，在某些場(chǎng)景下，這會(huì)導(dǎo)致集群失控，各主機(jī)的文件描述符被耗盡。

容器的健康檢查 (healthcheck): 在我看來(lái)，這是 Swarm mode 之外， Docker 1.12 引入的最關(guān)鍵功能，有了 healthcheck 這個(gè) feature，我們可以將業(yè)務(wù)內(nèi)部真正的健康狀況暴露出來(lái)了。這個(gè)功能落后于 Marathon 足足一年的時(shí)間。但可惜的是，服務(wù)（ service）創(chuàng)建目前還不支持這個(gè)關(guān)鍵詞，這就限制了服務(wù) (service) 異常重啟的能力，從而間接降低了服務(wù)容錯(cuò)能力。這一點(diǎn) Marathon 做的特別好。

資源控制： 1.12 目前支持單個(gè)任務(wù) CPU / mem 的資源控制。還無(wú)法像 Mesos 那樣，自由的配置管理磁盤(pán)， GPU，端口等資源。

無(wú)法使用主機(jī)網(wǎng)絡(luò)：通過(guò)服務(wù)（ service）啟動(dòng)的容器是無(wú)法使用主機(jī)網(wǎng)絡(luò)的 (network host is not eligible for Docker services)，但同時(shí)按照網(wǎng)絡(luò)上 Percona 提供的壓測(cè)結(jié)果， overlay 網(wǎng)絡(luò)相較于主機(jī)網(wǎng)絡(luò)有 60% 的性能損耗。這嚴(yán)重局限了 Swarm 的應(yīng)用場(chǎng)景，我們可以認(rèn)為這是編排功能帶來(lái)的架構(gòu)副作用。而 Mesos 從資源維度管理集群很好的規(guī)避了這個(gè)問(wèn)題。

接下來(lái)讓我們看看下一層：Docker 是怎樣在 stack, service, task container 之間建立聯(lián)系的？同一個(gè) stack 內(nèi)的 service 又是如何相互發(fā)現(xiàn)的？

第一個(gè)問(wèn)題很好回答， service label 和 container name， Docker 通過(guò)在 service 上添加 label: com.Docker.stack.namespace=XXX 來(lái)標(biāo)示這個(gè) service 屬于哪一個(gè) stack。我們可以 inspect 一個(gè) service 看下：

Docker 通過(guò)特定格式的 container name 標(biāo)示這個(gè) container 隸屬于哪一個(gè) service 下面，如下圖所示：

容器名稱 merryfox_mysql.1.by842qrj7xhsne93yzfpjp367 代表該容器是服務(wù) merryfox_mysql 的任務(wù) 1 的容器。Docker 在很多地方使用了這種技巧來(lái)處理數(shù)據(jù)。而第二個(gè)問(wèn)題就引出了我們下面的——服務(wù)發(fā)現(xiàn)。

在談服務(wù)發(fā)現(xiàn)之前，我們簡(jiǎn)單討論下 Docker overlay 網(wǎng)絡(luò)的性能問(wèn)題，根據(jù) https://www.percona.com/blog/... 的網(wǎng)絡(luò)壓測(cè)結(jié)果，相較于 host 網(wǎng)絡(luò)， overlay 有 60% 的網(wǎng)絡(luò)性能損耗，問(wèn)題主要出在多 CPU 下網(wǎng)絡(luò)負(fù)載不均。同時(shí)容器無(wú)法在 Swarm 編排模式下使用 host 網(wǎng)絡(luò)，這帶來(lái)的問(wèn)題就是：在 Docker 1.12 Swarm mode 下網(wǎng)絡(luò)性能損耗無(wú)法避免。

與 Marathon / Mesos 的 Mesos-DNS、 bamboo 類似， Swarm 的服務(wù)發(fā)現(xiàn)也分為內(nèi)部服務(wù)發(fā)現(xiàn) (internal service discovery) 與外部服務(wù)發(fā)現(xiàn) (ingress service discovery)，這兩種服務(wù)發(fā)現(xiàn)使用了不同的技術(shù)。

如果想讓一個(gè)服務(wù)暴露到集群之外，我們需要借助 service create 的參數(shù) publish，該參數(shù)顯式的聲明將集群特定端口 PORT_N（集群端口 PORT_N 代表集群中所有主機(jī)的端口 PORT_N）分配給這個(gè)服務(wù)。這樣無(wú)論該服務(wù)的容器運(yùn)行在哪臺(tái)主機(jī)上，我們都可以通過(guò)集群中任何主機(jī)的 PORT_N 端口訪問(wèn)這個(gè)服務(wù)了。下圖可以形象的描述這個(gè)場(chǎng)景：

接下來(lái)，我們就可以把集群中部分或所有主機(jī)的 IP 加上述端口配置到我們的前置負(fù)載均衡器上對(duì)公網(wǎng)提供服務(wù)了。一般稱這種分布式的負(fù)載均衡策略為 routing mesh，在 Calico 網(wǎng)絡(luò)方案中也提到了類似的概念。由于沒(méi)有了中心化的負(fù)載均衡器，集群不會(huì)因某臺(tái)機(jī)器異常而導(dǎo)致整個(gè)服務(wù)對(duì)外不可用，很好的避免了單點(diǎn)問(wèn)題，同時(shí)也帶了可擴(kuò)展性。關(guān)于routing mesh這個(gè)概念的詳細(xì)介紹可以參考該鏈接(https://en.wikipedia.org/wiki...。

這里摘抄一個(gè)簡(jiǎn)短解釋：

A mesh network is a network topology in which each node relays data for the network. All mesh nodes cooperate in the distribution of data in the network.

上述就是 Swarm 的外部負(fù)載均衡（也可以稱為routing mesh），那么 Docker 在底層做了什么來(lái)實(shí)現(xiàn)上述功能的呢？如下圖所示：

在 Swarm 集群初始化時(shí)， Docker 會(huì)創(chuàng)建一個(gè) overlay 網(wǎng)絡(luò) ingress，同時(shí)在每個(gè)節(jié)點(diǎn)上創(chuàng)建與 ingress 關(guān)聯(lián)的 sandbox 網(wǎng)絡(luò)命名空間，這樣集群中的每個(gè)主機(jī)都變?yōu)榱?ingress 網(wǎng)絡(luò)的一部分；

當(dāng)我們創(chuàng)建 service 申請(qǐng)一個(gè) publish port 時(shí)， Docker 會(huì)通過(guò) Iptables rules 建立 主機(jī) IP:Port 到 sandbox IP:Port 間的映射，即 : 將對(duì)應(yīng)端口的包轉(zhuǎn)發(fā)給 ingress 網(wǎng)絡(luò)；

同時(shí)在 sandbox 網(wǎng)絡(luò)命名空間內(nèi)， Docker 通過(guò) Iptables rules ＋ IPVS 控制對(duì)應(yīng) 端口/ Port 的包負(fù)載均衡到不同的容器。這里 IPVS(IP virtual server) 的功能與 HAproxy 類似，承擔(dān)著 Swarm 集群內(nèi)部的負(fù)載均衡工作。

對(duì)于只供集群內(nèi)部訪問(wèn)的服務(wù)，無(wú)需使用上述 routing mesh，Swarm 還提供了一套內(nèi)部服務(wù)發(fā)現(xiàn) + 負(fù)載均衡。如下圖所示（這里我們只討論基于 VIP 的負(fù)載均衡方法）：

manager 會(huì)為該 service 分配一個(gè) VIP(Virtual IP)，并在內(nèi)部 DNS 上建立一條 VIP 與 service name 的映射記錄。注意這里的 DNS server 也是分布式的，每一個(gè)主機(jī)上都有一個(gè) DNS server ；
Iptables 配合 IPVS 將 VIP 請(qǐng)求負(fù)載到 service 下面的一個(gè)具體容器上。

另外，主機(jī)間 routing mesh，load balancing rule 等信息是利用gossip協(xié)議進(jìn)行數(shù)據(jù)同步的，限于篇幅，這里不再深究這個(gè)問(wèn)題。

最后友情提示幾個(gè)雷區(qū)：

Q1：為什么我的機(jī)器無(wú)法加入 (join) 到 Swarm 集群中？終端報(bào)錯(cuò)：加入集群超時(shí)。
A1：這個(gè)問(wèn)題極有可能是主機(jī)間時(shí)鐘不同步導(dǎo)致的，建議開(kāi)啟 ntp 服務(wù)，同步主機(jī)時(shí)間。

Q2：為什么我在 manager A 上通過(guò)命令 Docker network create 的 overlay 網(wǎng)絡(luò)無(wú)法在集群另外的機(jī)器 B 上通過(guò) Docker network ls 發(fā)現(xiàn)？
A2: 這有可能是正常的。按 Swarm 當(dāng)前的設(shè)計(jì)，只有使用相應(yīng)網(wǎng)絡(luò)的容器被調(diào)度到了機(jī)器 B 上， overlay 網(wǎng)絡(luò)信息才會(huì)更新到機(jī)器 B 上去。

Q3: 為什么我的服務(wù)的 publish port 在有些機(jī)器上不生效？我使用 netstat – lnp 方式看不到端口監(jiān)聽(tīng)。
A3: 與問(wèn)題 1 一樣，這也可能是時(shí)鐘不同步導(dǎo)致的問(wèn)題。

參考鏈接：
http://collabnix.com/archives...
https://sreeninet.wordpress.c...