容器“撩”存儲手段升級，容器存儲接口（CSI）勝出
容器雖然不是一個新事物，但是國內的市場應該沒有起來，國外好點，但是總體來說，容器目前的市場空間還不夠大。尤其最近這段時間，據我了解，國內有幾個圍繞容器的創業公司融資困難，面臨破產的風險。
但我覺得容器還是一個未來的方向，這個市場會慢慢起來的，而且，我們也發現，很多追求創新的公司，已經開始在生產系統上部署容器了。
根據Gartner在IOCS 2018 Conference上的調查，容器部署到生產系統的比例已經高達27%。當然，這個主要是調查的對象，即參會的企業都是追求創新的企業。
而且，有22%的受訪者認為，到2020年，容器將是其主要的計算抽象，而不是虛擬機。
容器設計當初，其實是不需要***存儲的，但是，現在容器越來越多部署到生產環境中，很多數據需要***保存的，容器沒了，但數據不能沒。因此，容器支持***存儲就是業界一個熱門的話題。容器要使用外部存儲，一般通過卷插件來支持(參考我原來的文章傳言微軟要收購Docker，存儲廠商紛紛推出原生卷插件)。
但是，由于編排平臺部署和運營容器環境日益普及，大多數IT***現在都在尋找可與容器編排器(如Kubernetes)緊密集成的持久存儲解決方案。通過這種方法，編排器將能夠以一致的方式集中與許多外部存儲平臺通信，提供數據服務，并集中執行存儲生命周期和卷編排。
但剛開始，編排器只是把少數的卷插件集中到發行版里進去了，這種方式叫in-tree存儲插件。這種方式雖然可以和容器編排器協作了，但是缺點非常明顯：
存儲卷插件開發與Kubernetes版本緊密結合并依賴于Kubernetes版本。
Kubernetes開發人員/社區負責測試和維護所有供應商的卷插件，而不僅僅是測試和維護標準插件API。
卷插件中的錯誤會影響Kubernetes的穩定性，因為它們以完全權限運行。
存儲供應商被迫使插件源代碼可用，并且不能僅發布二進制文件。
由于in-tree存儲插件支持的存儲有限，如果你的存儲不在支持范圍內，那么你就必須開發自己的插件，但是，這個插件沒有標準，各家做各家的，和編排器的版本還是耦合太緊。
為解決該技術的問題，2018年，云原生計算基金會(Cloud Native Computing Foundation-CNCF)發布了Kubernetes 1.13，它GA了容器存儲接口(Container Storage Interface---CSI)。CSI把容器存儲進行抽象，通過標準接口的形式把存儲部分移到容器編排系統外部去。
CSI是在容器編排系統(如Kubernetes，Docker或Mesosphere)之間集成存儲系統驅動程序的***方法。CSI的目標是為容器編排系統建立標準化機制，以將任意存儲系統暴露給其容器化工作負載。CSI規范源自各種容器編排系統的社區成員之間的合作，包括Kubernetes，Mesos，Docker和Cloud Foundry。該規范獨立于Kubernetes開發，并保持在容器存儲接口(CSI)規范 。這個新接口是對容器生態系統的重大改進，因為它標準化了將外部存儲系統與許多容器編排系統集成的模型。特別是對于Kubernetes，它使存儲系統驅動程序免于被綁定到Kubernetes發布計劃，因為它被合并到相同的代碼庫中。通過CSI，現在可以開發存儲系統驅動程序并將其異步安裝到容器編排版本，從而提供更快的開發和錯誤修復。
使用CSI，存儲供應商不必為每個容器編排或開源提供多個驅動程序，不需要將他們的代碼以in-tree方式集成到容器編排器中，從而節省時間并加快開發速度。對于IT而言，CSI的使用將使更容易的設置，標準化配置以及針對容器化工作負載的存儲解決方案的無縫集成和遷移。
由于容器的編排器最火當算Kubernetes莫屬，因此，如果你也采用這個編排器，建議盡快升級到1.13版本，就可以***支持CSI接口了，以后升級編排器，再也無需關注存儲插件了。
而且，我剛才看了一下https://kubernetes-csi.github.io/docs/drivers.html(大家可以點擊文后的閱讀原文鏈接查看)，發現其實已經蠻多存儲產品開始支持CSI接口了。
不過，我們看到，傳統存儲產品很少，大部分是SDS類型的產品。還有，我們看到，中國的廠商在里面也發揮了重要作用：***我們看到華為創立的OpenSDS開源項目也已經支持了CSI，第二我們看到XSKY是唯一支持CSI接口的中國公司。XSKY在容器環境確實做了比較多工作，大家感興趣可以看看其官微的一篇文章：詳解支持 kubernetes CSI的持久化容器存儲。
由于CSI的種種好處，Gartner最近在其《An I&O Leader’s Guide to Storage for Containerized Workloads》也建議，負責規劃和支持基礎設施交付的I&O負責人應：
- 選擇與Kubernetes更緊密集成并支持標準接口(如CSI)的供應商，同時避免使用專有插件和接口。
- 選擇符合微服務架構原則的存儲解決方案，并遵循容器本機數據服務的要求，例如與硬件無關，API驅動，基于分布式架構，并能夠支持邊緣，核心或公共云部署。
- 選擇與開發人員工作流工具緊密結合的存儲產品，這些工具可以直接與應用層集成，以實現可移植性，擴展和數據保護。
- 評估供應商提供的持續創新，優質客戶支持和一致的定價模型，因為容器生態系統正在通過未經證實的供應商業務模型快速發展。
