docker 編排工具 2017最佳選擇是 swarm/kubernetes/Mesos ？

01-08

請大神們指導
1：docker 編排工具 2017最佳選擇是 swarm 還是 kubernetes？
2：什麼需求下使用swarm，反之什麼需求下選kubernetes，優劣勢？
3：就目前（2017年）swarm vs kubernetes 誰更有優勢及將來發展前景？
4：創業公司（大數據）是否更應該選擇kubernetes對docker（hdfs，spark，hb，hive....）進行編排，是否有大規模集群成功案例？

公司項目是微服務架構。以前伺服器端技術上主要是openstack+spring cloud，目前已經遷移到k8s。

遷移之後，

近一半spring cloud做的組件被砍掉。因為k8s和spring cloud的功能其實高度重合，spring cloud的服務發現、負載均衡之類的基礎組件都沒存在必要了。

openstack組件全部砍掉了。線上基礎設施用aws全家桶，部署以前用heat，現在用k8s deployment。

swarm在選型階段嘗試過，總結一下對k8s和swarm的看法：

1. 上手。swarm上手比k8s簡單得多。新手學習swarm，只需稍微了解一下命令，一天上手，一周就能玩得很溜。而新手學習k8s，免不了要先學一堆新概念，然後才能動手摺騰，沒人指點少不了各種磕磕碰碰，因此新手學k8s半個月起步，三個月手熟。

2. 功能。k8s功能比swarm強。k8s一整套解決方案用起來，運維太輕鬆了。swarm不是說它不好，但目前還是玩具級別。

3. 發展。k8s社區比swarm和mesos活躍。github的星數、提交數、貢獻者都是swarm和mesos的好多倍。代碼迭代也很快，十天八天一個patch版本，三兩個月一個minor版本。

4.硬體要求。k8s起步的硬體要求略高，master要一台機器專門跑。如果master還要求高可用，那至少佔用3台機器。

總的來說，docker公司懂容器，但google更懂集群管理。

選擇docker+kubernetes，就是選擇了正確的大腿。

什麼需求下都kubernetes。

功能甩其它一條街，UI甩兩條街。

開始我們上docker，用了個不常見的方式，openstack+nova-docker，自己調用openstack的api。後來openstack升級了一個字母的版本，尼瑪，api層完全變了，一點兼容性都沒有，徹頭徹尾不一樣。。。只有又重寫了一遍功能實現。

試用kubernetes，發現開發了大半年的需求，kubernetes都有，還實現的更好。。。

推薦用kubernetes，並且openstack一生黑。

最後生產環境的資料庫和大數據的方案，我們都用的物理機，並且不打算做虛擬化。

供參考。

這裡比較一下Mesos和Kubernetes, 至於Swarm，我個人覺得還是一個玩具而已。先說結論，在這個時間點上來看 Kubernetes 已經贏得了一定的優勢，並且優勢有一定擴大的可能性

先看一組GitHub在這個時間的上的數據：

過去一個月

Mesos: 3126 stars, ,1265 forks. 33/247 (last month/total) contributors

Marathon: 3258 stars, 746 forks, 17/234 (last month/total) contributors

Chronos: 3707 stars, 500 forks, 14/109 (last month/total) contributors

Kubernetes:23522 stars, 8300 forks, 196/1216 (last month/total) contributors

我們可以看出，從社區和貢獻者的角度來看。Kubernetes 現在遠遠領先於Mesos。從貢獻者的分布來看，Kubernetes的貢獻者有大量來自Google 之外（CoreOS, Redhat）的人員。相比較，Mesos現在主要還是由Mesosphere一家提供支持。可以說在這一點上Kubernetes遠遠勝出。

Kubernetes的劣勢在於它還沒有一個比較大的成功案例。而Mesos有Twitter這個最早的使用者，以及之後的Apple, Uber和Netflix等案例。但是值得注意的一點，Mesos的這些案例，沒有一個是使用DC/OS 或Marathon的。它們要麼是自研的Framework，要麼是Aurora。Mesos的優勢有兩點，第一點是先發優勢，起始於2009，並於2012在Twitter正式投入使用，在很大程度上讓大家終於有了一個Borg的山寨版。其對於資源的抽象和調度，對於那些自己運行數據中心的用戶，有著極大的吸引力。隨後Docker的橫空出世，更是添了一把火。相比之下，ubernetes 在2015年才進入大家的視野，直到近一年才開始走入成熟期。要知道今天那些在生產環境中大規模使用容器和資源編排的主兒，立項的時候大多是一到兩年前。那時候, 選擇Mesos是很自然的。但由於出現的較早，Mesos 對於Docker的支持等都是後來添加的，不比Kubernetes一出世就很好的支持Docker。Mesos的第二點優勢是比較靈活，由於可以運行不同的Framework，有實力的公司可以自研一套。這個特別對於集成現有系統有很大幫助。

拋開這一點，從商業角度來看，Mesosphere和Docker 公司一樣，一直陷入平衡開源與盈利的壓力和困境。在過去一年裡，一系列的舉動和重心都傾斜於試圖推廣自家的DC/OS。而相比之下，Kubernetes已經成為Google Cloud的這盤棋的一部分，自身完全不必考慮掙錢。特別最近又得到了眾多盟友的支持。看起來風生水起， CNCF 有聲有色。從歷史上來看，Kubernetes這種模式勝出的幾率很大

其實對於那些要搞混合雲的以及和Google Cloud 競爭的公司來說。 Mesosphere 是一個很好的收購對象, 上一輪估值不過6億美元。大膽預測一下，18個月內，Mesosphere 會被收購。金主可能在Microsoft, VMWare, Oracle, IBM之中。華為也可以努力一把。

回答下樓豬的問題，以下是小弟淺見，分享給大家相互討論下：

1. 編排工具的選擇主要取決於企業的內部IT架構未來的發展方向。如果僅僅是小規模運算而業務也不大的情況下，使用Swarm比較合適。原因很簡單~~「小而美」易上手，學習和部署成本較低。另外，如果你有Windows系統的需求，你們你就一定只能選擇Swarm；

2.上面第一點已經說明，如果有Windows的場景，只能使用Swarm，目前Google的K8S還暫時不支持Windows。但是如果有大規模計算場景和希望投入到生產環境，用K8S比較適合，集群管理會做的更優秀；

3.這個很難講，但是就目前 K8的社區會更加活躍。且在過去一年裡面明顯K8的進步比Swarm要快很多。這個也是因為Google的背景原因，產品的價值會體現比較明顯；

4.如果是創業公司的大數據，由於公司業務剛開始，且業務量一開始不會太大，所以自己使用公有雲的大數據平台或者自己買台伺服器搭建大數據也足以支撐了。國外有家叫Rancher的公司有一些關於大數據的Docker實踐案例，有空可以Google參考下。

A：方案一多，大家都選擇困難，別緊張，做到「知己知彼」，就不會再糾結。

「知己」說的是，需求和現狀。需求包括：跨主機通信到底要解決啥問題呢，能聯通就可以還是要一容器一 IP，後續要隔離嗎，有沒有網路 ACL 控制需求，需要做 traffic shapping 嗎？現狀包括：容器（應用）規模多大，是自建 IDC 嗎，多少運維力量，後續會上公有雲嗎？

「知彼」說的是，要理解各個容器網路方案的功能和限制。這個就需要一個一個去了解，可以參考各個項目的文檔，也可以網上搜集一些文章。

接下來，就是按照需求和現狀來挑選合適的方案了。下面舉幾個例子：

1. 如果規模小，只是簡單的連通性需求，建議直接 docker swarm 就可以了；

2. 規模中等，有自由機房和運維力量，建議 macvlan，性能好，簡單；

3. 容器規模相對大，後續可能上公有雲，建議嘗試 calico，性能好，有 ACL 策略控制；

4. 有錢，已經上了思科的網路設備，對 SDN 有需求，考慮 contiv，可以集成 ACI，利用 Openflow 可以有部分 SDN 功能；

5. 技術實力夠，對操作系統的內核有控制權，建議上 cilium （對內核有要求，4.8+），優勢是性能，安全相關特性豐富；

6. 如果現有的都不滿足需求，擼起袖子自己干也可以。

Docker Swarm與Apache Mesos的區別

集群高可用／容錯

Docker Swarm 與 Mesos 都可以通過一致性中間件構造高可用集群。Mesos 的 Master 節點一般通過 ZooKeeper 保證高可用，而 Docker Swarm 的 manager 節點可以通過 consul、etcd 或 ZooKeeper 中的任意一個來保證高可用。但是從目前 Docker Swarm 的架構來看，Swarm manager 節點的高可用不是必需的，因為即使 manager 節點宕機了，Swarm 的原有服務也不會受到影響。我還有一種更極端的想法， Swarm 集群平時不需要 manager 節點，只有在需要 metrics 信息，發布新的應用，或者健康檢查時再啟動 manager 服務即可，這是因為 manager 節點目前的功能非常單一，像容器的健康檢查，失敗重啟等功能還沒有實現，文檔中提到的資源管理，以及服務中斷等機制也都沒有詳細的介紹，我估計應該還在開發中。

對於swarm要區分兩個概念，Docker swarm 和swarm mode，前一個已經出現在官方的棄用列表中，取而代之的是後者，後者能夠實現的功能更為強大，使用起來也極其方便。

參考：巔峰對決之Swarm、Kubernetes、Mesos

容器編排選擇希雲csphere。如果您的企業想花錢省心地解決問題優先推薦希雲csphere產品。