摘要：由于沒有了中心化的負(fù)載均衡器，集群不會因某臺機器異常而導(dǎo)致整個服務(wù)對外不可用，很好的避免了單點問題，同時也帶了可擴展性。

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

正文開始前先八卦一下，關(guān)注 Docker 技術(shù)的小伙伴們應(yīng)該清楚 Docker 1.12 的 Swarm mode 頗受爭議：首先是有人認(rèn)為 Docker 公司 Market Drive Develop，違背了 Linux 信徒恪守的哲學(xué)——一個工具只干一件事情；其次， 有人認(rèn)為 Swarm mode 的功能不及 Mesos 和 K8S，還不適合生產(chǎn)環(huán)境使用，這一點我倒認(rèn)為穩(wěn)定性而不是功能才是 Swarm 目前不適合生產(chǎn)環(huán)境的原因；最后， Docker 的向后兼容性不足也引來口水無數(shù)，畢竟 Docker 還在 active develop。其它的像容器網(wǎng)絡(luò)標(biāo)準(zhǔn)的爭議， Runc 的爭議這些都把 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)系。上述幾個概念的關(guān)系如下圖所示：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

與 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ù)。

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

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

這里摘抄一個簡短解釋：

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 在底層做了什么來實現(xiàn)上述功能的呢？如下圖所示：

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

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

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

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

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

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

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

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

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

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

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