容器“撩”儲存手段升級，容器儲存介面（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驅動，基於分散式架構，並能夠支援邊緣，核心或公共雲部署。
- 選擇與開發人員工作流工具緊密結合的儲存產品，這些工具可以直接與應用層整合，以實現可移植性，擴充套件和資料保護。
- 評估供應商提供的持續創新，優質客戶支援和一致的定價模型，因為容器生態系統正在通過未經證實的供應商業務模型快速發展。