[[265202]]

目前，容器存儲是容器離不開的一個話題，對于無狀態的Docker容器，容器重啟時容器數據會自動清除，一些靜態的數據我們可以通過配置文件或者在容器build時直接寫死。但是對于數據庫、日志文件等可以實時變化的數據，我們不能夠通過這種方法存取,容器的存儲大多支持Docker或Kubernetes的Volume(數據卷)，因此我們下文先介紹這兩種Volume的原理。

Docker的容器卷插件

Docker V1.8正式發布了容器卷插件 (Volume Plugin) 的規范，允許第三方廠商的數據卷在Docker引擎中提供數據服務，使得外置存儲可以超過容器的生命周期而獨立存在。這意味著各種存儲設備只要滿足接口API的標準，就可以接入Docker容器的運行平臺中。Volume Plugin的接口規范定義了5中操作，如下表所示：

這個規范定義非常簡潔，現有的各種存儲可以通過簡單的驅動程序封裝，從而實現和Docker容器的對接?？梢哉f，驅動程序實現了和容器引擎的北向接口，底層則調用后端存儲的功能完成數據存取等任務。還有不少存儲方案實現了額外的高端功能，如容器數據卷遷移等，這部分功能不在Docker的卷插件規范當中，可通過存儲自身的管理工具來使用。目前已經實現的Docker Volume Plugin中，后端存儲包括常見的NFS, CIFS, GlusterFS和塊設備等。

Kubernetes的容器卷

Kubernetes是開源的容器集群管理平臺，可以自動化部署、擴展和運維容器應用。Kubernetes的調度單位稱作“Pod”(豆莢)，每個Pod代表一個應用，包含一個或多個容器。Pod可部署在集群的任意節點中，存儲設備可以通過數據卷(Volume)提供給Pod的容器使用。Kubernetes底層支持Docker的容器運行引擎，為了不綁定在特定的容器技術上，Kubernetes沒有使用Docker的Volume機制，而是重新制定了自己的通用數據卷插件規范，以配合不同的容器運行時來使用(如Docker和rkt)。

數據卷一般可以貫穿Pod的整個生命周期，當Pod被平臺刪除的時候，在不同的數據卷實現中，數據可能會被保留或移除。如果數據被保留的話，其他Pod可以重新把該卷的數據加載使用。數據卷分為共享和非共享兩種類型，其中非共享型只能被某個節點掛載使用(如iSCSI，AWS EBS等網絡塊設備)，共享型則可以讓不同節點上的多個Pod同時使用(如NFS，GlusterFS，CephFS等網絡文件系統，以及可支持多方讀寫的塊設備)。對有狀態的應用來說，共享型的卷存儲能夠很方便地支持容器在集群各節點之間的遷移。

Kubernetes的數據卷可把外部預創建的數據卷接入Pod里面，在這個過程中，Pod無法對數據卷配置參數(如卷大小，IOPS等)，因為這些參數是由提供數據卷的存儲預先設定的，這有點象傳統存儲先劃分數據卷，再供給應用掛載使用。為了給容器提供更細粒度的卷管理，Kubernetes增加了持久化卷PV(Persistent Volume)的功能，把外置存儲作為資源池，由平臺管理并提供給整個集群使用。每個PV具有一些可被平臺感知的存儲能力，如卷容量(storage size)，讀寫訪問模式(access mode)等。當Pod需要存儲時，可以向平臺請求所需要存儲資源，該請求稱作PVC (Persistent Volume Claim)。PVC內容包括訪問模式、容量大小等信息。平臺根據請求的資源屬性(如卷大小等)匹配合適的資源并分配給Pod，并把數據卷掛載到Pod所在的主機中供Pod使用(如下圖所示)。

Kubernetes的Persistent Volume功能還在不斷發展中，目前PV僅支持存儲容量(storage size)的能力(capacity)，今后還可能支持IOPS，吞吐量等存儲能力，以便配置更豐富的存儲策略。Kubernetes的卷管理架構使得存儲可用標準的接入方式，并且通過接口暴露存儲設備所支持的能力，從而在容器任務調度等方面實現了自動化管理。

Flocker

為了給容器應用提供文件卷存儲，比較簡單的方式是在重用傳統存儲的基礎上，加上適配容器規范的相應接口。使用這種方式的容器存儲很多，如適配Docker的GlusterFS, NFS, CIFS的卷插件。下文介紹的Flocker也是這種模式的開源容器卷管理器，它提供了在集群中管理和編排容器數據卷的方案，并依靠后端的共享塊存儲提供數據卷跨主機的能力。

如上圖所示，Flocker由控制服務作為總控制器，對外提供REST API接口，負責維持和更新系統的狀態。Flocker Agent安裝在集群的每個節點上，負責確保每個節點上的本地狀態符合系統期待的狀態，如果發現本地狀態和期待狀態不符，Flocker Agent將采取必要的糾正措施，使得節點上的數據卷與集群系統的配置實現最終一致性(eventual consistency)。Flocker Plugin也部署在每個節點上，主要以插件形式與Docker、Kubernetes等容器平臺的集成，不僅讓容器可以使用Flocker提供的數據卷，還能夠支持容器的遷移。

例如，在Kubernetes中，當Pod所在的主機失效之后，Kubernetes會把Pod重新調度(遷移)到另一臺主機上，相應地，Flocker把Pod在原主機上的數據卷釋放出來，并且在新主機中重新掛載給該Pod。這樣，有狀態容器在遷移主機的時候，其數據卷也能夠跟隨著容器一起移動。

Flocker后端可采用各種常見的網絡塊設備，包括AWS EBS，OpenStack Cinder，EMC、DELL、NetApp、VMware VSAN/vVOL等，這些塊設備配上驅動程序，即可由Flocker生成數據卷(文件目錄形式)，掛接到任意的主機上，再通過卷插件的接口，把數據卷提供給容器應用。

Portworx

Portworx開發了容器感知的軟件定義存儲系統，稱為CDS (Container-Defined Storage)。在Portworx的CDS存儲中，采用的是計算和存儲融合的架構，把集群中所有節點的本地存儲聚合成大的資源池，使得每個節點既提供計算能力，也提供本地磁盤作為存儲，這樣運行在節點中的容器可從本地直接訪問數據。

任何存儲都要保證數據的完整性和可靠性，由于Portworx采用分布式存儲架構，與Ceph、VMware Virtual SAN等類似，需要在多節點之間進行數據復制。如上圖所示，當數據在本地寫入的時候，根據存儲設定的參數，可以把數據復制到其他若干個節點中，從而在集群中存有多個數據副本，確保了數據的可用性和可靠性。如果某個節點出現故障或進行下線維護，該節點上的容器可以被上層的調度器重新調度到其他節點上。因為數據已經復制到了多個節點，容器在新節點上可直接使用本地數據，提高了數據訪問的效率(如下圖所示)。

Portworx還設計了面向容器卷的存儲策略，在創建數據卷的時候可以動態設置，這些策略如下所示：

通過設置上述存儲屬性的配置，容器卷的QoS等需求可以動態滿足，與傳統的SAN等塊存儲有很重要的區別：這些策略是以容器卷的粒度進行配置的，能夠很好地符合容器應用的需求，所以稱為容器定義的存儲(Container Defined Storage)，是為容器應用量身定制的軟件定義存儲。目前，Portworx在架構上實現了軟件定義存儲的控制平面和數據平面。盡管許多功能還在不斷完善之中，但是我們還是可以看出下一代面向容器的軟件定義存儲的雛形。