容器儲存架構比較：Kubernetes、Docker和MesosCompare

本文講的是容器儲存架構比較：Kubernetes、Docker和Mesos Compare【編者的話】 容器儲存是容器離不開的一個話題，對於無狀態的Docker容器，容器重啟時容器資料會自動清除，一些靜態的資料我們可以通過配置檔案或者在容器build時直接寫死。但是對於資料庫、日誌檔案等可以實時變化的資料，我們不能夠通過這種方法存取。結合場景這次主要談下Docker的儲存方式，以及主要儲存方式的對比。

【3 天燒腦式基於Docker的CI/CD實戰訓練營 | 北京站】本次培訓圍繞基於Docker的CI/CD實戰展開，具體內容包括：持續整合與持續交付（CI/CD）概覽；持續整合系統介紹；客戶端與服務端的 CI/CD 實踐；開發流程中引入 CI、CD；Gitlab 和 CI、CD 工具；Gitlab CI、Drone 的使用以及實踐經驗分享等。

“There is no such thing as a stateless architecture” —— Jonas Boner

任何應用程式都需要資料支撐，這也是我們商業存在基石。最初，容器應運而生的主要目的之一也是為了解決無狀態服務。但短期時間內，隨著技術的不斷成熟，允許容器化應用程式直接訪問資料的需求也在不斷的增加。現代化的應用程式和傳統的應用程式都需要諸如檔案、塊，或者工具化檔案儲存物件、關係型資料庫、流媒體檔案等這些不同型別的儲存。

虛擬機器也可以管理應用程式，但是這種方法對硬體模擬有一定的要求，容器可以保證應用程式的可移植性遠大於虛擬化的實現。實際應用程式的可移植性的能力，還依賴於個容器編排工具的互操作性。對於當前的原生雲應用程式，儲存也是一個很關鍵的元件，因為應用程式可以利用持久儲存平臺以及圍繞其特性進一步開發特性功能。通過Clinton Kitson`s的部落格：理解原雲應用儲存獲取更多資訊。

容器的協調者和執行時對儲存服務發起特定的請求，可以實現諸如建立/刪除、檢查/清單、附加/分離、安裝/解除安裝等操作。這是解決容器協調者之間儲存問題的一種獨特的嘗試，不過在行業中也是有分歧的。對外儲存編排請求API分為兩種情況：首先，是in-tree驅動程式，它是直接將原生程式碼編譯到容器協調器；第二，是out-of-tree，藉助於外部外掛驅動。每一種方式都有自己的優缺點：in-tree驅動器受制於容器協調器的釋出週期；而out-of-tree外掛式驅動可能無法提供與容器協調器繫結的增強特性集。

Docker

Docker是在1.7的實驗版本中通過建立Docker Volume 驅動介面首次解決了外部儲存的問題。1.13版本中Docker又引入了外掛模型，也就是Docker Store。通過查詢目錄/run/docker/plugins，Docker發現並可使用UNIX外掛（.sock檔案），這是一個使用out-of-tree模型的例子。

UNIX域套接字（ Unix domain socket）檔案必須在相同的Docker主機上執行。但如果指定了遠端訪問URL，外掛也可以通過spec和json配置檔案實現在不同的主機上執行。實現儲存功能的集中化，這也是外掛職責之一。該介面接受JSON、RPC型別的HTTP請求。out-of-tree模型公開的介面提供了完整的Volume生命週期，也為Docker CLI提供了編排功能。但是，如快照或複製等高階儲存功能，還未提供暴露給Docker CLI。

Mesos

Mesos直到v0.23版本才開始支援本地儲存。Mesos-Module-Dvdi就是為這個問題而提出的方案，隨後它的特性被合併到Mesos，直到Mesos 1.0+版本方能使用。DVDCLI是將Docker Volume Driver CLI打包封裝到Mesos中，允許在所有的Mesos容器內使用任何Docker Volume驅動，Mesos-Module-Dvdi就是利用正在實施中的DVDCLI實現了本地儲存。與Docker類似，框架與DVDCLI互聯通訊支援JSON格式，並且也提供使用JSON/RPC通過HTTP與Docker Volume Driver Interface通訊。

正如前面所提及的，由於它使用了Docker Volume 驅動，因此它是一個out-of-tree外掛，並且具有和Docker CLI相同的Volume生命週期和限制。

Kubernetes

Kubernetes的獨特之處在於它既有in-tree又有out-of-tree驅動。我們已經在“Kubernetes儲存說明”和“Kubernetes 1.6版本中關於儲存的新功能“這兩篇文章中詳細說明，我們再次回顧下：

in-tree驅動來自於Kubernetes原始碼，也是其標準發行版的一部分。通過這些驅動，可以根據Kubernetes提供的介面（如Mount/Umount、Create/Delete等）向其儲存平臺暴露API，Kubernetes執行所有功能，並向驅動程式執行特定的API呼叫，從而執行所需的操作。這也可以充分利用Kubernetes的特性，比如：動態供應的儲存類。這樣也是有缺點的，如果系統BUG或增加需要新增一些平臺特性，則依賴於Kubernetes的釋出週期。釋出週期可能意味著3-6個月的等待修復、持續維護、回合程式碼等流程。

Out-of-tree驅動使用Flexvolume介面。Flexvolume允許使用者編寫自己的驅動程式，並在Kubernetes中新增對其Volume的支援。供應商的驅動應該被安裝在在每個Kubelet節點和主節點上，Volume外掛的路徑：usr/libexec/kubernetes/kubelet-plugins/volume/exec/<vendor~driver>/。這使得驅動程式可以在核心的Kubernetes程式碼之外執行，並且可以根據自己的時間節點表釋出更新或者修復BUG。Flexvolume介面預期Volume的建立和刪除可以基於外部外掛進行。因此，Flexvolume只使用Attach/Detach 和 Mount/Unmount功能，而不是整個Volume的生命週期。

當前總概

把所有的儲存功能結合在一起，我們可以看到這是一個非常碎片化的空間，以及三者之間各有千秋。

而所有這一切都意味著儲存供應商需要建立多層次封裝整合，從而支援整個容器生態系統。容器儲存介面（CSI）專案處於早期階段，但最終將會成為儲存和容器成功的關鍵因素。

與此同時，我們已經將所有的功能整合，並且整合了針對每一種容器協調者功能的儲存方法。我們深知當前和未來的容器化應用程式依賴儲存，而且這個解決方案適應每一個場景：Docker和Mesos中的REX-Ray，FlexREX和Kubernetes，Docker中的REX-RAY外掛，Kubernetes的本地ScaleIO驅動程式。

原文連結：Container Storage Architectures: How Does Kubernetes, Docker, and Mesos Compare?（翻譯：ylzhang）

原文釋出時間為：2017-08-11

本文作者：ylzhang

本文來自雲棲社群合作伙伴Dockerone.io，瞭解相關資訊可以關注Dockerone.io。

原文標題：容器儲存架構比較：Kubernetes、Docker和Mesos Compare