?一、引言

Kubernetes從版本1.0以后，引入了兩個新的 API 資源：PersistentVolume 和 PersistentVolumeClaim 實(shí)現(xiàn)了對存儲供應(yīng)的獨(dú)立管理。持久卷（PersistentVolume，PV） 是對存儲資源在集群中的抽象；持久卷聲明（PersistentVolumeClaim，PVC）則是用戶對存儲資源的請求。盡管PV和PVC已經(jīng)實(shí)現(xiàn)了對用戶存儲資源請求的管理，但是管理員仍需手動創(chuàng)建各種類型的PV 實(shí)現(xiàn)對用戶的存儲供應(yīng)。為了實(shí)現(xiàn)存儲資源的動態(tài)供應(yīng)，Kubernetes從版本1.4以后就引入了存儲類（StorageClass）資源。自1.9版本以后，Kubernetes又引入了容器存儲接口（Container Storage Interface CSI），將存儲驅(qū)動代碼從Kubernetes的核心庫中剝離了出來，在Kubernetes和外部存儲間引入了一套標(biāo)準(zhǔn)的存儲管理接口，使得外部存儲可以通過實(shí)例化該接口動態(tài)為容器提供存儲資源。本文將從上述資源對象入手，對Kubernetes的存儲管理進(jìn)行簡要說明，并簡述G行在容器存儲管理上的實(shí)踐。

二、PV和PVC

1、PV

PV（PersistentVolume） 是集群中存儲資源，一般由管理員創(chuàng)建或者由StorageClass自動創(chuàng)建。他們不同于普通的volume，其生命周期獨(dú)立于Pod存在。PV主要包括了存儲能力、訪問模式、存儲類型、回收策略、后端存儲類型等關(guān)鍵信息的描述。下文我們來創(chuàng)建一個PV，YAML如下：

針對這個例子，我們來對PV的關(guān)鍵屬性進(jìn)行簡要描述：

• Capacity：描述指定存儲設(shè)備的存儲能力，目前僅支持對存儲大?。╯torage）的設(shè)置，未來可能支持IOPS、吞入量等；
• VolumeMode：Kubernetes支持兩種存儲卷模式：Filesystem（文件系統(tǒng)）和Block（塊設(shè)備），默認(rèn)值為Filesytem。當(dāng)VolumeMode指定為Filesystem時，Kubernetes會在首次掛載時實(shí)現(xiàn)對文件系統(tǒng)的初始化；當(dāng)VolumeMode指定為Block時，則會以原始塊設(shè)備的形式掛載給Pod，Pod和Volume之間不會有任何文件系統(tǒng)層；
• AccessModes：描述用戶對存儲資源的訪問權(quán)限，需要注意的是一個PV在同一時刻只能以一種訪問模式被掛載，其可選的訪問模式包括：a. ReadWriteOnce（RWO）：卷可以被一個節(jié)點(diǎn)以讀寫方式掛載，可以被同一節(jié)點(diǎn)上的多個Pod訪問；b. ReadOnlyMany（ROX）：卷可以被多個節(jié)點(diǎn)以只讀方式掛載；c. ReadWriteMany（RWX）：卷可以被多個節(jié)點(diǎn)以讀寫方式掛載；d. ReadWriteOncePod（RWOP）：卷可以被單個Pod 以讀寫方式掛載。此模式必須需要CSI支持以及需要 Kubernetes 1.22 以上版本。
• StorageClassName：指定的存儲類別（StorageClass），只有StorageClassName相同的PV和PVC才能進(jìn)行綁定。若StorageClassName不進(jìn)行設(shè)置，則會被設(shè)置為集群默認(rèn)的 StorageClass。

2、PVC

PVC 是用戶對存儲資源的申請，主要包括了存儲空間請求、訪問模式、選擇條件和存儲類別等信息的描述。集群根據(jù)PVC的描述為其選擇匹配的PV進(jìn)行綁定。下面我們來創(chuàng)建一個PVC，YAML如下：

針對這個例子，我們來對PVC的關(guān)鍵屬性進(jìn)行簡要描述：

• Resources：描述對存儲資源的請求，例如存儲大?。╮equests.storage）；
• VolumeMode：存儲卷模式，其設(shè)置跟PV的設(shè)置相同；
• AccessModes：訪問模式，其設(shè)置跟PV的設(shè)置相同；
• StorageClassName：存儲類別（StorageClass）名稱，當(dāng)系統(tǒng)設(shè)置了StorageClass，則系統(tǒng)會自動為PVC創(chuàng)建相應(yīng)的PV并進(jìn)行綁定；
• Selector：選擇器，PVC會根據(jù)selector的內(nèi)容對滿足條件的PV進(jìn)行篩選，選擇KV匹配的PV進(jìn)行綁定。

PVC根據(jù)上述屬性描述選擇與之匹配的PV進(jìn)行綁定，需要注意的是，PVC只會在相同的Namespace內(nèi)選擇PV，同樣的，Pod也只能掛載相同的Namespace的PVC。只有當(dāng)PVC選擇到合適的PV時，才可以被Pod進(jìn)行正常掛載，示例如下：

3、PV和PVC的生命周期

PV生命周期的各個階段：

• Available（可用）：尚未與任何PVC進(jìn)行綁定；
• Bound（已綁定）：已經(jīng)綁定到某個PVC；
• Released（已釋放）：所綁定的PVC已被刪除，但是資源尚未被集群回收；
• Failed（失敗）：卷自動回收操作失敗。

PV和PVC的相互關(guān)系如下圖1所示的生命周期：

圖1

Kubernetes提供了兩種存儲資源的供應(yīng)模式：

靜態(tài)模式：集群管理員必須聯(lián)系存儲管理員手動來創(chuàng)建新的存儲卷， 然后在 Kubernetes 集群創(chuàng)建 PersistentVolume 對象來表示這些卷，最后用戶創(chuàng)建PVC進(jìn)行綁定。

動態(tài)模式：集群管理員無需手動創(chuàng)建PV卷，通過配置StorageClass來實(shí)現(xiàn)對存儲類的管理和資源的動態(tài)供應(yīng)。用戶申請PVC時，指定StorageClassName，對應(yīng)的StorageClass將會自動完成對應(yīng)存儲類的存儲卷創(chuàng)建以及Kubernetes集群中PV的創(chuàng)建。若StorageClassName聲明為"", 則說明該P(yáng)VC禁止使用動態(tài)模式。

三、StorageClass和CSI

1、StorageClass

動態(tài)供應(yīng)模式主要基于StorageClass對象實(shí)現(xiàn)，集群管理員可以針對不同的存儲類型創(chuàng)建不同的StorageClass，對用戶屏蔽了底層存儲的細(xì)節(jié)?；赟torageClass的動態(tài)存儲供應(yīng)逐步成為了云平臺的標(biāo)準(zhǔn)存儲配置模式。StorageClass主要包括了存儲提供者以及相關(guān)存儲參數(shù)的配置。StorageClass一旦創(chuàng)建，則不能被修改，只能刪除重建。示例如下：

示例聲明一個名為standard，由Kubernetes.io/aws-ebs提供的存儲類。

2、CSI

StorageClass提供了存儲動態(tài)供應(yīng)的功能，但是各種后端存儲插件的代碼都必須被放入Kubernetes的主干代碼中以供調(diào)用，這種緊耦合的開發(fā)模式，導(dǎo)致了巨大的維護(hù)成本和諸多問題。因此Kubernetes基于上述考慮，推出了容器存儲接口標(biāo)準(zhǔn)（CSI）。各存儲提供方自行維護(hù)自己的存儲插件代碼，只要滿足CSI 標(biāo)準(zhǔn)，即可讓Kubernetes進(jìn)行調(diào)用，無需再耦合在Kubernetes的主干代碼中。CSI 存儲插件的標(biāo)準(zhǔn)實(shí)現(xiàn)主要包含兩種組件：

Controller Plugin：Controller主要實(shí)現(xiàn)存儲資源和存儲類的管理，一般為單實(shí)例部署，可以部署在任意節(jié)點(diǎn)上。

Node Plugin：主要實(shí)現(xiàn)對Node上存儲卷的管理和操作，包括卷的掛載、卸載等，一般部署為Daemonset，每個Node上運(yùn)行一個Pod。

四、G行的容器存儲管理實(shí)踐

1、背景

G行在云平臺3.0之前已經(jīng)引入了集中式NAS存儲，在用戶需要申請PV卷時，需要先向存儲管理員提出申請，然后由存儲管理員在存儲端按用戶需求創(chuàng)建一塊存儲卷，再由系統(tǒng)管理員在集群中手動創(chuàng)建PV卷完成資源交付，最后用戶在系統(tǒng)中創(chuàng)建PVC完成資源申請，流程如下圖2所示：

圖2

從上述流程描述可以看出，整個過程中需要大量人為介入，缺乏自動化。Kubernetes本身提供了StorageClass 用于支持資源的動態(tài)創(chuàng)建，因此G行考慮在現(xiàn)有基礎(chǔ)上引入CSI存儲插件，實(shí)現(xiàn)了自動化存儲交付。并在原有的基礎(chǔ)上，引入了高性能本地存儲和分布式SAN存儲，擴(kuò)充了存儲資源類型。

2、CSI的部署與實(shí)踐

圖3

CSI的部署過程如上圖3所示，過程相對比較復(fù)雜，每次Kubernetes集群創(chuàng)建后，若都需要手動部署CSI插件，無疑會增加系統(tǒng)運(yùn)維的成本。G行在此基礎(chǔ)上引入APP標(biāo)準(zhǔn)化交付框架，將Kubernetes的集群創(chuàng)建操作，以及CSI插件的部署進(jìn)行了集成，實(shí)現(xiàn)了Kubernetes集群的一鍵化創(chuàng)建，標(biāo)準(zhǔn)化交付。當(dāng)集群創(chuàng)建完成后，相應(yīng)的CSI插件及StorageClass就已經(jīng)自動完成了部署，用戶即可直接使用。

集群中已經(jīng)部署好用戶所需的StorageClass，存儲資源申請只需直接創(chuàng)建PVC即可，示例如下：

剛創(chuàng)建完的PVC的狀態(tài)為Pending。

CSI的Controller會Watch kube-apiserver，檢測StorageClass的provisioner為自身的PVC的變化，當(dāng)感知到PVC的創(chuàng)建后，會自動去存儲端進(jìn)行存儲卷的創(chuàng)建，存儲卷創(chuàng)建完以后，Controller會自動在集群中創(chuàng)建PV。

圖4

整個過程結(jié)束后，可以在集群中看到PV已經(jīng)被成功創(chuàng)建，PVC的狀態(tài)已經(jīng)變?yōu)榱薆ound。

從圖4上述過程可以看出，用戶申請存儲資源的整個流程中，無需存儲管理員和集群管理員手動干預(yù)，即可自動存儲資源交付。

3、使用CSI支持動態(tài)擴(kuò)容

在云平臺3.0中，G行在云平臺3.0中的引入了高性能本地存儲和分布式SAN存儲，這兩類存儲在存儲層基于KVM動態(tài)擴(kuò)容技術(shù)可實(shí)現(xiàn)對后端存儲卷的動態(tài)擴(kuò)容。在容器平臺中，G行對相應(yīng)的CSI Controller進(jìn)行了升級優(yōu)化，實(shí)現(xiàn)了EXPAND_VOLUME的功能，響應(yīng)用戶的擴(kuò)容需求。當(dāng)CSI Controller在Watch到相應(yīng)的修改后，會調(diào)用存儲后端接口對相應(yīng)的存儲卷和PV卷進(jìn)行擴(kuò)容，并對文件系統(tǒng)根據(jù)相應(yīng)設(shè)置進(jìn)行調(diào)整。

首先在存儲插件部署時，需要將StorageClass的allowVolumeExpansion字段設(shè)置為True，開啟動態(tài)擴(kuò)容，StorageClaas配置示例如下：

對于正在運(yùn)行中的業(yè)務(wù)，若用戶有擴(kuò)容需求，無需卸載其使用的PV卷，直接修改PVC的requests大小，CSI Controller則立即嘗試調(diào)用存儲后端接口對相應(yīng)的存儲卷和PV卷進(jìn)行擴(kuò)容，后端存儲在接收到擴(kuò)容需求后，調(diào)用virsh blockresize命令調(diào)整存儲卷大小，并將處理結(jié)果返回給CSI Controller。CSI Controller確認(rèn)存儲卷已經(jīng)擴(kuò)容后，找到當(dāng)前存儲卷所掛載的node節(jié)點(diǎn)，請求相應(yīng)的node節(jié)點(diǎn)上的CSI Daemonset對擴(kuò)容卷進(jìn)行resize，將擴(kuò)容的容量擴(kuò)充進(jìn)文件系統(tǒng)中。至此，用戶的動態(tài)擴(kuò)容需求就完成了。整個擴(kuò)容流程，用戶無需暫停業(yè)務(wù)，業(yè)務(wù)連續(xù)性和穩(wěn)定性得到了保障。

4、多種CSI并行

G行在云平臺3.0中支持了集中式NAS存儲、高性能本地存儲和分布式SAN存儲，并針對這三類存儲類進(jìn)行了性能測試，針對測試結(jié)果梳理了相應(yīng)的用戶使用場景，部分測試數(shù)據(jù)如下（測試數(shù)據(jù)僅供參考）：

集中式NAS存儲：作為文件存儲，讀寫性能弱于塊存儲，原生支持文件系統(tǒng)的多節(jié)點(diǎn)讀寫，適用于有文件共享需求的用戶使用。

分布式SAN存儲：分布式塊存儲，讀寫性能好。在存儲模式為Filesystem時不支持多節(jié)點(diǎn)讀寫，適用于對存儲性能要求較高，無共享存儲需求的用戶使用。

高性能本地存儲：本地塊存儲，讀寫性能好。同樣不支持Filesystem存儲模式下的多節(jié)點(diǎn)讀寫，適用于單存儲卷容量300G以下，無共享存儲需求，對存儲性能要求高的用戶使用。

五、總結(jié)

Kubernetes通過PV、PVC、StorageClass、CSI標(biāo)準(zhǔn)構(gòu)建了一套完善的存儲管理機(jī)制，G行充分利用Kubernetes資源對象，并針對行內(nèi)現(xiàn)狀，引入多種存儲類型和對應(yīng)的CSI存儲插件，實(shí)現(xiàn)了多種CSI并行及自動化容器存儲管理。存儲管理員和系統(tǒng)管理員無需再手動創(chuàng)建存儲卷和PV卷，只需在項(xiàng)目創(chuàng)建之初，針對不同的存儲類（StorageClass）給項(xiàng)目分配存儲配額。用戶需要時，可直接創(chuàng)建PVC，CSI 控制器會根據(jù)用戶的PVC參數(shù)，調(diào)用存儲端接口，自動創(chuàng)建存儲卷以及PV卷，實(shí)現(xiàn)了用戶的即時申請，即時可用，當(dāng)用戶有擴(kuò)容需求時，現(xiàn)有CSI控制器也可支持PV卷的動態(tài)擴(kuò)容，無需管理員手動調(diào)整。相比靜態(tài)交付管理的模式，集群管理員無需預(yù)先配置存儲，既降低了人力成本，又提升了交付效率和業(yè)務(wù)的連續(xù)性。同時，多種存儲類的引入也滿足了不同使用場景下的用戶需求。