Docker 1.12 Swarm 模式剖析

Docker 1.12 在 2016 年 7 月 28 日正式 GA，除了大量的在使用上的改進和 bug 修複外，最引人矚目的是原生支援了 Swarm 模式。

熟悉 Docker 的讀者都知道 Docker Swarm 是官方三劍客之一，提供了輕量級容器雲的支援，以性能卓越出名，跟 K8s 面向應用的較為複雜的容器雲方案一時瑜亮，各有千秋。

本次 Swarm 模式特性的釋出可謂重要變革，不僅僅是減低使用門檻那麼簡單，還引入了不少新的圍繞應用的特性，從中可以一探 Docker 團隊對于容器雲的理念。

基本概念

Swarm 定義為一組合作在一起的 Docker 主機叢集，由節點組成，每個節點都是一個獨立的 Docker 主機。

叢集中包括兩種節點：管理節點和工作節點。參考 k8s 的結構，也是如此。

• 管理節點：負責對任務進行排程和其它管理任務，多個管理節點通過 Raft 協定組成叢集；
• 工作節點：負責運作具體的任務，管理節點可以同時作為工作節點。

如果把所有節點配成管理+工作，那就是絕對的對等了，實際上從性能角度考慮，管理節點數量不宜過多，并且互相之間的網際網路絡要保證好的品質。

此外，還引入了服務的概念。服務也包括兩種類型：

• 複制服務（replicated services）：類似 k8s 中複制集的概念，保持一定數量的相同任務在叢集中運作；
• 全局服務（global services）：類似 k8s 中 daemon 的概念，每個工作節點上運作一個。

一個服務由多個任務組成，一個任務即一個運作的容器。

主要特性

負載均衡和服務位址管理

k8s 中讓人印象深刻的是它的服務自帶了負載均衡和服務位址功能，Swarm 也通過 ingress load balancing （基于 ipvs 的四層代理）來實作，為每一個服務提供一個 DNS 位址，維護一個公共的端口。這點上跟 k8s 預設方式略有不同，但效果是一緻的，都保證了無論容器如何變化，任意節點對應用的通路保持不變。

跨主機網絡

這點還是基于 overlay 網絡來實作。

監控管理

基于服務的概念，對運作狀态進行管控，自動保持服務的運作狀态。

支援指令

目前圍繞對叢集和服務進行管理，指令都很容易了解。

• swarm init
• swarm join
• service create
• service inspect
• service ls
• service rm
• service scale
• service ps
• service update

Swarm2k

很有意思的項目，就是基于最新的 Swarm 模式來在全球範圍内建構一個超過 2000 個節點，1 M 個容器的大叢集。

目前已經達到預定目标，具體可以關注 [這裡]（https://github.com/swarm2k/swarm2k/blob/master/PROPOSAL.md）。

這個項目的成功，也再次證明官方的 Swarm 方案，在性能上确實首屈一指！

小結

跟 Docker 技術自身的火爆不同，Docker 團隊一直以來就面臨着未來發展的困境，幾乎所有人都希望他們隻安心做好容器引擎。但作為一個商業化公司來說，這樣下去毫無疑問是自掘深坑。于是，他們積極的在基于容器的各種平台和工具上進行建構。包括三件套、包括容器雲，都是很好的嘗試。

從 Swarm 的特性來看，Docker 團隊在應用為中心這點上是認同了 K8s 的理念的，但是自身又同時保持了一定的獨立性。這對于 Docker 來說自然是利好。但是目前來看，并沒有完全解決團隊發展的困境。

轉載請注明：http://blog.csdn.net/yeasy/article/details/52098902。