聊聊調度框架，K8S、Mesos、Swarm 一個都不能少

Swarm、Mesos、和Kubernetes都為各種規模的企業提供了全面的支持，如何選擇是好？

API

▼

目前找到符合企業自身需求的調度框架比較困難，Docker Swarm、Mesos、Kubernetes三大巨頭之間最大的區別在可擴展性方面，Swarm的 Zero To Dev 快速設置功能擁有巨大的優勢，Docker API的靈活性讓它易於集成，並允許使用其他工具，如定製腳本或編寫的自定義介面以及複雜的調度。

Swarm：易於集成和設置，靈活的API，有限的定製 Kubernetes：高度通用，開源、 Mesos：適用於大型系統

Kubernetes和Mesos在定製方面都比較通用，不過對於用戶的友好度偏低，如果正在集成或更改其中一個就不得不從頭開始，不適合相對較小的團隊。

可伸縮性&彈性

▼

在可伸縮性和彈性方面，Mesos對於運行著大規模集群的公司來說是最好的選擇，在模擬測試中，其最高可以運行5萬多個節點，Kubernetes和Swarm都被限制在1000個節點（大約5萬個容器）。同時Mesos在大規模解決方案實踐上擁有強大的話語權，如Twitter這樣的大公司都在使用。

Swarm：適合中小型系統，在這個範疇它的價值和可擴展性最好 Kubernetes：適合中等規模高度冗餘的系統 Mesos：目前最穩定的平台，適合大規模系統

於中型企業來說，Kubernetes在多主機集群中具有可靠性和較強的容錯力，不過成本較高，因為應用插件的數量越多，就需要越好的安全方案，然而Kubernetes在AWS的覆蓋上存在問題，所以很多人會在選擇時猶豫不決。

在這三種調度框架做出選擇需要進行驗證：根據應用的工作方式，數量、以及如何管理數據等基礎，可以幫助縮小選擇範圍。下面在容器存儲架構方面對三者進行比較：

存儲架構

▼

容器在應用的可移植性方面遠遠超出了虛擬機所能達到的程度，虛擬機監控應用對硬體有一定的要求，實現應用可移植性的能力要依賴容器之間的相互操作，即便使用雲計算應用存儲也是一個關鍵的組件：應用可以利用持久性的存儲平台，並圍繞它的一些特性進行開發。

容器安裝和運行時對存儲服務進行特定的請求，以實現如：創建/刪除、檢查/列表、連接/分離、掛載/卸載等功能。這導致了解決容器「存儲問題」的一些獨特的嘗試與分歧，將存儲編排到外部平台的API請求有兩種可能：

一個 In-Tree Driver 在容器編配器中構建的本地代碼 一個使用插件的Out-Tree Driver

這兩者各有利弊，In-Tree收到容器編配程序的發布周期限制，Out-Of-Tree插件可能無法提供與容器協調器綁定的增強特性集。

Docker

Docker1.7通過創建Docker 容量驅動程序介面來解決外部存儲問題，在1.13版本中將商店引入，UNIX插件可以通過在/run/docker/插件的目錄進行查找，這是使用Out-Of-Tree的例子之一。

UNIX文件必須在相同的Docker主機上運行，而帶有規範或Json文件的插件如果指定了遠程URL可以在不同的主機上運行，該介面通過HTTP接受Json/rpc，Out-Of-Tree的介面為Docker CLI提供了完整的存儲卷生命周期和編排功能。

Mesos

在Mesos V0.23之前，它支持本地存儲， Mesos-Module-Dvdi 為解決這個問題應運而生，隨後它的特性出現在上游，現在Mesos 1.0+中也可以使用。該模塊利用名為DVECLI的項目，將Docker存儲卷驅動程序CLI打包為Mesos，可以使用任何一個Docker存儲卷應用和Mesos容器使用，與Docker類似，它也使用了Json，允許框架與DVDCLI對話，並使用HTTP/rpc來與Docker存儲卷驅動介面進行對話。

和Docker CLI一樣，它也有相同的功能和限制。

Kubernetes

Kubernetes的獨特之處在於它兼容In-Tree和Out-Of-Tree，In-tree驅動是Kubernetes的本地代碼，是其標準的一部分，這些驅動程序會根據Kubernetes提供的介面公開API命令，如掛載/卸載、創建/刪除等等，Kuberneters執行這些功能，實現Pod的創建，並向驅動程序執行特定的API調用執行所需的操作，這也可以利用Kubernetes的特性，如動態配置和存儲，缺點是，會過於依賴發布周期，可能需要3-6個月的時間等待修復和持續維護或重新建立代碼。

Out-Of-Tree驅動程序使用Flexvolume介面，允許用戶編寫自己的驅動程序，並在Kubernetes中添加對其存儲卷的支持，供應商應該在存儲卷插件路徑：usr/libexec kubernetes kubelete-plugins/volume/exec/<vendor~driver>/。

這讓驅動程序可以在核心的Kubernetes代碼之外運行，特性更新和BUG修復也能在自己的時間表上發布，Flexvolume介面期望在其外部發生存儲卷創建和刪除操作，因此，只有連接/分離和掛載/卸載能力可用，而不是整個存儲卷的生命周期。

下圖可以看到其不同之處：

存儲供應商需要創建多個集成，支持跨容器的生態系統，容器存儲介面（CSI）項目正處於早期階段，但這將是存儲和容器成功的關鍵性因素。

如何選取最適合自身團隊的調度框架，以下幾點可以參考：

如果想更好的構建和打包應用，或想加速微服務的話，Docker容器和開發工具是最好的選擇 若是DevOps團隊，且想構建專用於Docker編排的系統，在人員和時間充足的情況下，選擇Kubernetes最合適 想建立運行多個任務可靠的平台，且需要較強的可移植性那麼Mesos比K8S和Docer的優勢更加明顯

原文作者：Kendrick Coleman 原文鏈接：https://blog.codedellemc.com/2017/06/27/container-storage-architectures-kubernetes-docker-mesos-compare/?utm_source=tuicool&amp;utm_medium=referral