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。
