[[265202]]

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

Docker的容器卷插件

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

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

Kubernetes的容器卷

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

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

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

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

Flocker

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

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

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

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

Portworx

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

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

Portworx還設計了面向容器卷的存儲策略，在創(chuàng)建數(shù)據(jù)卷的時候可以動態(tài)設置，這些策略如下所示：

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