聊聊容器存儲介面CSI的那些事兒

在不同的編排器Kubernetes、Mesos、Docker Swarm之間，它們有不同的介面來訪問存儲資源，例如Docker有外掛程式機制的DVDI介面，Mesos＆Pivotal Cloud Foundry也使用一些Docker介面，Kubernetes具有本地驅動程式（其中卷驅動程式是原始程式碼樹的主要部分）——提供外部API和當前CSI的Flex驅動程式；還有一些API框架和工具，

如Rex-Ray，OpenSDS等，提供其他方式來連接存儲……為提供一個標準的API，供多種編排器和多個存儲提供商使用，簡化它們之間的介面，CSI誕生了！

CSI（容器存儲介面）是要定義一個行業標準，使存儲供應商（SP）能夠一次開發一個外掛程式，並在多個容器編排器（CO）系統中工作。

Kubernetes 1.9 引入了CSI（ 容器存儲介面）的 Alpha 實現（相關參考 2），這一功能讓安裝新的存儲卷外掛程式像部署 Pod 一樣簡單。

同時給協力廠商存儲提供商無需加入 Kubernetes 核心代碼，即可開發存儲的接入方案。

這一特性在 1.9 中還處於 Alpha 階段，因此必須顯式啟用。雖說 Alpha 功能不推薦在生產環境中使用，但這是對項目方向的一個指引，CSI 就是在宣導一個更加易於擴展且更標準化的 Kubernetes 存儲生態。

Dell開源專案組{code}一直在佈道雲原生模式和容器技術的未來優勢，該項目組對CSI（容器存儲介面）投入很大，近日{code}技術總監Clint Kitson就此話題發表觀點，闡述了雲原生時代存儲模式和CSI之所以關係重大的三點理由。

今天，很明顯我們能夠認識到我們為什麼需要這樣一個標準，容器通過動態管理應用讓我們能夠解決一些很困難的問題，容器生態系統中人、社區和企業正在認真地創造越來越強大的交互操作工具來推進落地。

然而，在管理存儲時，我們都撞上了一堵牆，“每個人都以不同的方式來做”。

電腦行業已經認識到，創建標準介面多麼美好——它作為基本規則，最大限度地減少使用者的混淆。沒有它們，會出現大量的複雜性和碎片化問題。制定標準就像制定家庭裝修的藍圖，通過記錄電源插座應該放置的位置，住在裡面的人就可以知道插入插頭的位置，

並自行決定安裝什麼小工具，而不用擔心如何為其供電，可能存在哪些限制。

CSI就是由容器編排器—— Mosos、Kubernetes、Cloud Foundry和Docker領導的一個社區驅動的計畫，它定義一個滿足其管理的應用存儲需求的介面。我們都希望擁有容器賦能的更智慧、更強大的應用。

我認為CSI之所以重要有三個基本原因：

1：CSI提供KISS和社區方法

它並不像以往的整合存儲的方式，在某些方面，它提供了更多的細節和功能。

但是，早期的項目，如果不落實，就會變得焦點分散和難以完成。參與者會難以合作，因為有這麼多的決定讓人分心。

因此，CSI採用最簡單的方法：認識到人們今天如何使用容器和存儲，但要以介面規範和可插拔的形式來使用。簡單——“保持簡單，傻瓜式！”（KISS）的方法 ——使CSI首先關注基礎。結果——我們希望CSI能夠提供容器編排器和存儲平臺之間的更好的集成，這樣我們可以反覆運算改進，並依靠它來構建更好的應用。

2：CSI為更多用例提供可預測的功能性介面

構建所有類型的介面都會面臨的一種挑戰是，開發人員和資料中心專業人員需要一個易於掌握的使用者體驗，同時支援使用它的應用的深度功能集。

例如，Docker為其卷驅動程式創建了一個規範，它還有一些改進的空間。當故障發生時，它的介面不能正常處理情況。如果一個元件出現故障，很難重新同步到正確的狀態。

我不是針對Docker。我們有很多的介面被定義，但沒有一個是完美的例子。

CSI團隊正在盡力從不完善之處有所學習。我們希望擴展與存儲相關的設計模式，與更多的應用程式一起工作。

例如，我們目前只引入具有檔案系統的卷。當一個應用程式需要存儲資料時，它必須抓取一個帶有檔案系統的卷。對於CSI，我們支援原始塊設備 ——這是基本的，但目前尚不可用。用戶可以定義沒有檔案系統的卷。這使得新應用能夠運行於與邏輯塊位址配對的容器。實際上，需要高性能或在主機間共用設備的應用可能更喜歡這樣。

3. CSI由用戶需求和社區驅動，而非存儲公司

CSI自上而下的設計來自於容器編排工具和社區。為了簡單起見，團隊成員沒有大跨步前進，而是採用“做一點，但做得非常好”的老派方法。對我來說，這可能是CSI最重要的一個方面。

所有從事CSI工作的人都試圖使規範與使用它的人相關。這個團隊並沒有根據任何存儲公司能夠提供什麼以及他們想要賣給你的東西來做出決定。

相反，CSI小組考慮的問題包括：“這個問題怎麼解決？誰是解決問題的合適人選？什麼是理想的解決方案？如何實施？“

CSI如何改變你的生活？

如果說技術人員會討厭什麼東西，那可能就是被迫選擇一種工具。如果CSI取得成功，它將確保企業不會僅僅因為特定的存儲支援或特定的雲提供商而選擇一家容器平臺。這將提高所有平臺的交互品質。這裡的成功給大家帶來了一個一次性的複雜任務，而一步鞏固了存儲的動態管理和可攜性的雲原生模式。這將使每個人的工作變得更容易。

相關參考

https://kubernetes.io/docs/concepts/storage/volumes/

https://github.com/kubernetes/features/issues/178

https://github.com/kubernetes/community/blob/master/contributors/devel/flexvolume.md

https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md

https://github.com/kubernetes-csi/docs/wiki/Setup

https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md#third-party-csi-volume-drivers

https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md#recommended-mechanism-for-deploying-csi-drivers-on-kubernetes

https://github.com/kubernetes-csi/external-attacher

https://github.com/kubernetes-csi/external-provisioner

https://github.com/kubernetes-csi/driver-registrar

https://github.com/kubernetes-csi/drivers

https://github.com/kubernetes/community/blob/master/contributors/devel/flexvolume.md

並依靠它來構建更好的應用。

2：CSI為更多用例提供可預測的功能性介面

構建所有類型的介面都會面臨的一種挑戰是，開發人員和資料中心專業人員需要一個易於掌握的使用者體驗，同時支援使用它的應用的深度功能集。

例如，Docker為其卷驅動程式創建了一個規範，它還有一些改進的空間。當故障發生時，它的介面不能正常處理情況。如果一個元件出現故障，很難重新同步到正確的狀態。

我不是針對Docker。我們有很多的介面被定義，但沒有一個是完美的例子。

CSI團隊正在盡力從不完善之處有所學習。我們希望擴展與存儲相關的設計模式，與更多的應用程式一起工作。

例如，我們目前只引入具有檔案系統的卷。當一個應用程式需要存儲資料時，它必須抓取一個帶有檔案系統的卷。對於CSI，我們支援原始塊設備 ——這是基本的，但目前尚不可用。用戶可以定義沒有檔案系統的卷。這使得新應用能夠運行於與邏輯塊位址配對的容器。實際上，需要高性能或在主機間共用設備的應用可能更喜歡這樣。

3. CSI由用戶需求和社區驅動，而非存儲公司

CSI自上而下的設計來自於容器編排工具和社區。為了簡單起見，團隊成員沒有大跨步前進，而是採用“做一點，但做得非常好”的老派方法。對我來說，這可能是CSI最重要的一個方面。

所有從事CSI工作的人都試圖使規範與使用它的人相關。這個團隊並沒有根據任何存儲公司能夠提供什麼以及他們想要賣給你的東西來做出決定。

相反，CSI小組考慮的問題包括：“這個問題怎麼解決？誰是解決問題的合適人選？什麼是理想的解決方案？如何實施？“

CSI如何改變你的生活？

如果說技術人員會討厭什麼東西，那可能就是被迫選擇一種工具。如果CSI取得成功，它將確保企業不會僅僅因為特定的存儲支援或特定的雲提供商而選擇一家容器平臺。這將提高所有平臺的交互品質。這裡的成功給大家帶來了一個一次性的複雜任務，而一步鞏固了存儲的動態管理和可攜性的雲原生模式。這將使每個人的工作變得更容易。

相關參考

https://kubernetes.io/docs/concepts/storage/volumes/

https://github.com/kubernetes/features/issues/178

https://github.com/kubernetes/community/blob/master/contributors/devel/flexvolume.md

https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md

https://github.com/kubernetes-csi/docs/wiki/Setup

https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md#third-party-csi-volume-drivers

https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md#recommended-mechanism-for-deploying-csi-drivers-on-kubernetes

https://github.com/kubernetes-csi/external-attacher

https://github.com/kubernetes-csi/external-provisioner

https://github.com/kubernetes-csi/driver-registrar

https://github.com/kubernetes-csi/drivers

https://github.com/kubernetes/community/blob/master/contributors/devel/flexvolume.md