在不同的編排器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 核心代碼，即可開發存儲的接入方案。

[[226960]]

這一特性在 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