在不同的編排器Kubernetes、Mesos、Docker Swarm之間，它們有不同的接口來訪問存儲資源，例如Docker有插件機制的DVDI接口，Mesos＆Pivotal Cloud Foundry也使用一些Docker接口，Kubernetes具有本地驅(qū)動程序（其中卷驅(qū)動程序是源代碼樹的主要部分）——提供外部API和當(dāng)前CSI的Flex驅(qū)動程序；還有一些API框架和工具，如Rex-Ray，OpenSDS等，提供其他方式來連接存儲……為提供一個標(biāo)準(zhǔn)的API，供多種編排器和多個存儲提供商使用，簡化它們之間的接口，CSI誕生了！

CSI（容器存儲接口）是要定義一個行業(yè)標(biāo)準(zhǔn)，使存儲供應(yīng)商（SP）能夠一次開發(fā)一個插件，并在多個容器編排器（CO）系統(tǒng)中工作。

Kubernetes 1.9 引入了CSI（ 容器存儲接口）的 Alpha 實現(xiàn)（相關(guān)參考 2），這一功能讓安裝新的存儲卷插件像部署 Pod 一樣簡單。同時給第三方存儲提供商無需加入 Kubernetes 核心代碼，即可開發(fā)存儲的接入方案。

[[226960]]

這一特性在 1.9 中還處于 Alpha 階段，因此必須顯式啟用。雖說 Alpha 功能不推薦在生產(chǎn)環(huán)境中使用，但這是對項目方向的一個指引，CSI 就是在倡導(dǎo)一個更加易于擴展且更標(biāo)準(zhǔn)化的 Kubernetes 存儲生態(tài)。

Dell開源項目組{code}一直在布道云原生模式和容器技術(shù)的未來優(yōu)勢，該項目組對CSI（容器存儲接口）投入很大，近日{(diào)code}技術(shù)總監(jiān)Clint Kitson就此話題發(fā)表觀點，闡述了云原生時代存儲模式和CSI之所以關(guān)系重大的三點理由。

今天，很明顯我們能夠認(rèn)識到我們?yōu)槭裁葱枰@樣一個標(biāo)準(zhǔn)，容器通過動態(tài)管理應(yīng)用讓我們能夠解決一些很困難的問題，容器生態(tài)系統(tǒng)中人、社區(qū)和企業(yè)正在認(rèn)真地創(chuàng)造越來越強大的互操作工具來推進落地。然而，在管理存儲時，我們都撞上了一堵墻，“每個人都以不同的方式來做”。

計算機行業(yè)已經(jīng)認(rèn)識到，創(chuàng)建標(biāo)準(zhǔn)接口多么美好——它作為基本規(guī)則，最大限度地減少用戶的混淆。沒有它們，會出現(xiàn)大量的復(fù)雜性和碎片化問題。制定標(biāo)準(zhǔn)就像制定家庭裝修的藍(lán)圖，通過記錄電源插座應(yīng)該放置的位置，住在里面的人就可以知道插入插頭的位置，并自行決定安裝什么小工具，而不用擔(dān)心如何為其供電，可能存在哪些限制。

CSI就是由容器編排器—— Mosos、Kubernetes、Cloud Foundry和Docker領(lǐng)導(dǎo)的一個社區(qū)驅(qū)動的計劃，它定義一個滿足其管理的應(yīng)用存儲需求的接口。我們都希望擁有容器賦能的更智能、更強大的應(yīng)用。

我認(rèn)為CSI之所以重要有三個基本原因：

1：CSI提供KISS和社區(qū)方法

它并不像以往的整合存儲的方式，在某些方面，它提供了更多的細(xì)節(jié)和功能。但是，早期的項目，如果不落實，就會變得焦點分散和難以完成。參與者會難以合作，因為有這么多的決定讓人分心。

因此，CSI采用最簡單的方法：認(rèn)識到人們今天如何使用容器和存儲，但要以接口規(guī)范和可插拔的形式來使用。簡單——“保持簡單，傻瓜式！”（KISS）的方法 ——使CSI首先關(guān)注基礎(chǔ)。結(jié)果——我們希望CSI能夠提供容器編排器和存儲平臺之間的更好的集成，這樣我們可以迭代改進，并依靠它來構(gòu)建更好的應(yīng)用。

2：CSI為更多用例提供可預(yù)測的功能性接口

構(gòu)建所有類型的接口都會面臨的一種挑戰(zhàn)是，開發(fā)人員和數(shù)據(jù)中心專業(yè)人員需要一個易于掌握的用戶體驗，同時支持使用它的應(yīng)用的深度功能集。

例如，Docker為其卷驅(qū)動程序創(chuàng)建了一個規(guī)范，它還有一些改進的空間。當(dāng)故障發(fā)生時，它的接口不能正常處理情況。如果一個組件出現(xiàn)故障，很難重新同步到正確的狀態(tài)。

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

CSI團隊正在盡力從不完善之處有所學(xué)習(xí)。我們希望擴展與存儲相關(guān)的設(shè)計模式，與更多的應(yīng)用程序一起工作。

例如，我們目前只引入具有文件系統(tǒng)的卷。當(dāng)一個應(yīng)用程序需要存儲數(shù)據(jù)時，它必須抓取一個帶有文件系統(tǒng)的卷。對于CSI，我們支持原始塊設(shè)備 ——這是基本的，但目前尚不可用。用戶可以定義沒有文件系統(tǒng)的卷。這使得新應(yīng)用能夠運行于與邏輯塊地址配對的容器。實際上，需要高性能或在主機間共享設(shè)備的應(yīng)用可能更喜歡這樣。

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

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

所有從事CSI工作的人都試圖使規(guī)范與使用它的人相關(guān)。這個團隊并沒有根據(jù)任何存儲公司能夠提供什么以及他們想要賣給你的東西來做出決定。

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

CSI如何改變你的生活？

如果說技術(shù)人員會討厭什么東西，那可能就是被迫選擇一種工具。如果CSI取得成功，它將確保企業(yè)不會僅僅因為特定的存儲支持或特定的云提供商而選擇一家容器平臺。這將提高所有平臺的交互質(zhì)量。這里的成功給大家?guī)砹艘粋€一次性的復(fù)雜任務(wù)，而一步鞏固了存儲的動態(tài)管理和可移植性的云原生模式。這將使每個人的工作變得更容易。

相關(guān)參考

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