正如最初設想的，容器已經成為無狀態型微服務的最佳載體。容器的敏捷、靈活、小開銷，與微服務是絕配。因此，容器與DevOps琴瑟和諧，成為近十年的最熱門技術，就像裝上了火箭發動機一樣。
與此同時，“無狀態”的負面性，也開始呈現。真正的應用也用容器，但應用都是有狀態的。而且，大多數應用存在兩種存儲形式，數據交換和存檔采用第一種，(多種形式的)持久性存儲，運行中的應用實例和臨時庫則用第二種，臨時性存儲。
容器vs. 虛擬機
與虛擬機不同，應用在無狀態容器上運行時，實例是不會持久化的，一旦因任何原因出錯，不可能恢復。應用可以訪問容器所在主機的存儲，但除非容器及其載體也在虛擬機上，否則極易觸發安全隱患。反觀虛擬機，若當前主機上的實例出故障，虛擬機可以快速重啟另一主機上的實例。這一點是容器不被主流IT接受的最主要原因。
行之有效的微服務/小程序架構，需要數據在容器間移動，或者在數據所在地實例化容器服務，這樣通常更快。從敏捷和靈活性來看，確實需要一種跨容器的數據狀態載體。
現在，應用可在各種平臺上構建存儲，從對象到塊存儲，從SAN到超融合。對于想完全取代hypervisor的容器而言，滿足廣泛的存儲方案是完善生態的必經之路。
要說的是，不同玩家，理解上頗有一些哲學上的微妙差異。Hypervisor玩家嚷嚷著支持無狀態容器，是因為有狀態容器可能會終結hypervisor。一些容器玩家支持無狀態容器，也許是“原教旨主義”的體現——在容器的發展早期，“無狀態”是其區分hypervisor的一個重要賣點。
大多數容器用戶非常喜歡容器的敏捷、易用性。再加上一臺服務器能跑3-5倍多實例(相比虛擬機)的事實，簡直讓DevOps玩家到愛不釋手的地步。因此，為容器增加持久性存儲功能，一定是其產品變革的首選項。實際上，行業內的變化完全符合這一預期。
容器存儲，是一個亂象叢生，百家爭鳴的新領域，各家都在積極推出自己獨特的方案，彼此互不相容。這雖然讓用戶頭疼，但也正說明這一市場方興未艾。
產品和供應商
讓我們來看看形形色色的容器存儲方案。Portworx PWX允許容器掛載共享型的彈性塊存儲。StorageOS在此基礎上，還搭載各種類型/協議的外部存儲，并提供壓縮。Rancher Labs強項是本地存儲，同時支持跨服務器的數據遷移。微軟Windows Server提供面向OS內核和Hyper-V實例的共享解決方案。
另外，ClusterHQ使用Flocker，一種開源產品，允許創建跨容器甚至主機的共享存儲空間。Flocker本由VMware提供支持，且能與EMC、NetApp等主流供應商產品集成，但ClusterHQ選擇完全自主開發，因此就拒絕了VMware的強力支撐。
容器的核心層軟件堆棧也有動靜。Kubernetes 1.6及更高版本，允許按需存儲和多種存儲類型，包括所有主流云計算方案底層的StorageClass對象，OpenStack協議簇，VMware vSphere以及三大公有云服務供應商。超融合系統也秘而不宣地整合容器存儲，相信Nutanix等供應商不久就會公布升級計劃。
有趣的是，容器開發者們喜歡說“持久性數據”，而非“持久性存儲”。我一向覺得，傳統視野里的文件系統概念，在當前的對象存儲、軟件定義存儲/微服務、細粒度容器虛擬化等新思潮面前，已經過時了。技術演變的結果也許就是，一個全新的細粒度存儲。
NVDIMM的出現，這股變革熱潮也許將更迫切。幾年之內，NVDIMM就會將塊存儲單元從4KB降到單字節級，因此當前的容器存儲很可能完全不適應未來的需要，而持久性數據(存儲)才是一個正確的選擇。
京公網安備 11010502049343號