云原生存儲(chǔ)中的容器存儲(chǔ)與 K8s 存儲(chǔ)卷怎么理解

本篇文章為大家展示了云原生存儲(chǔ)中的容器存儲(chǔ)與 K8s 存儲(chǔ)卷怎么理解，內(nèi)容簡(jiǎn)明扼要并且容易理解，絕對(duì)能使你眼前一亮，通過(guò)這篇文章的詳細(xì)介紹希望你能有所收獲。

云原生存儲(chǔ)的兩個(gè)關(guān)鍵領(lǐng)域：Docker 存儲(chǔ)卷、K8s 存儲(chǔ)卷；

• Docker 存儲(chǔ)卷：容器服務(wù)在單節(jié)點(diǎn)的存儲(chǔ)組織形式，關(guān)注數(shù)據(jù)存儲(chǔ)、容器運(yùn)行時(shí)的相關(guān)技術(shù)；

• K8s 存儲(chǔ)卷：關(guān)注容器集群的存儲(chǔ)編排，從應(yīng)用使用存儲(chǔ)的角度關(guān)注存儲(chǔ)服務(wù)。

Docker 存儲(chǔ)

容器服務(wù)之所以如此流行，一大優(yōu)勢(shì)即來(lái)自于運(yùn)行容器時(shí)容器鏡像的組織形式。容器通過(guò)復(fù)用容器鏡像的技術(shù)，實(shí)現(xiàn)在相同節(jié)點(diǎn)上多個(gè)容器共享一個(gè)鏡像資源（更細(xì)一點(diǎn)說(shuō)是共享某一個(gè)鏡像層），避免了每次啟動(dòng)容器時(shí)都拷貝、加載鏡像文件，這種方式既節(jié)省了主機(jī)的存儲(chǔ)空間，又提高了容器啟動(dòng)效率。

1. 容器讀寫(xiě)層

為了提高節(jié)點(diǎn)存儲(chǔ)的使用效率，容器不光在不同運(yùn)行的容器之間共享鏡像資源，而且還實(shí)現(xiàn)了在不同鏡像之間共享數(shù)據(jù)。共享鏡像數(shù)據(jù)的實(shí)現(xiàn)原理：鏡像是分層組合而成的，即一個(gè)完整的鏡像會(huì)包含多個(gè)數(shù)據(jù)層，每層數(shù)據(jù)相互疊加、覆蓋組成了最終的完整鏡像。

為了實(shí)現(xiàn)多個(gè)容器間共享鏡像數(shù)據(jù)，容器鏡像每一層都是只讀的。而通過(guò)實(shí)踐我們得知，使用鏡像啟動(dòng)一個(gè)容器的時(shí)候，其實(shí)是可以在容器里隨意讀寫(xiě)的，這是如何實(shí)現(xiàn)的呢？

容器使用鏡像時(shí)，在多個(gè)鏡像分層的最上面還添加了一個(gè)讀寫(xiě)層。每一個(gè)容器在運(yùn)行時(shí)，都會(huì)基于當(dāng)前鏡像在其最上層掛載一個(gè)讀寫(xiě)層，用戶(hù)針對(duì)容器的所有操作都在讀寫(xiě)層中完成。一旦容器銷(xiāo)毀，這個(gè)讀寫(xiě)層也隨之銷(xiāo)毀。

如上圖所示例子，一個(gè)節(jié)點(diǎn)上共有 3 個(gè)容器，分別基于 2 個(gè)鏡像運(yùn)行。

鏡像存儲(chǔ)層說(shuō)明如下：

該節(jié)點(diǎn)上共包含 6 個(gè)鏡像層：Layer 1~6。

• 鏡像 1 由：Layer 1、3、4、5 組成；

• 鏡像 2 由：Layer 2、3、5、6 組成。

所以?xún)蓚€(gè)鏡像共享了 Layer 3、5 兩個(gè)鏡像層；

容器存儲(chǔ)說(shuō)明：

• 容器 1：使用鏡像 1 啟動(dòng)

• 容器 2：使用鏡像 1 啟動(dòng)

• 容器 3：使用鏡像 2 啟動(dòng)

容器 1 和容器 2 共享鏡像 1，且每個(gè)容器有自己的可寫(xiě)層； 
容器 1（2）和容器 3 共享鏡像 2 個(gè)層（Layer3、5）；

通過(guò)上述例子可以看到，通過(guò)容器鏡像分層實(shí)現(xiàn)數(shù)據(jù)共享可以大幅減少容器服務(wù)對(duì)主機(jī)存儲(chǔ)的資源需求。

上面給出了容器讀寫(xiě)層結(jié)構(gòu)，而讀寫(xiě)的原則：

對(duì)于讀：容器由這么多層的數(shù)據(jù)組合而成，當(dāng)不同層次的數(shù)據(jù)重復(fù)時(shí)，讀取的原則是上層數(shù)據(jù)覆蓋下層數(shù)據(jù)； 
對(duì)于寫(xiě)：容器修改某個(gè)文件時(shí)，都是在最上層的讀寫(xiě)層進(jìn)行。主要實(shí)現(xiàn)技術(shù)有：寫(xiě)時(shí)復(fù)制、用時(shí)配置。

1）寫(xiě)時(shí)復(fù)制

寫(xiě)時(shí)復(fù)制（CoW：copy-on-write），表示只在需要寫(xiě)時(shí)才去復(fù)制，是針對(duì)已有文件的修改場(chǎng)景。CoW 技術(shù)可以讓所有的容器共享 image 的文件系統(tǒng)，所有數(shù)據(jù)都從 image 中讀取，只有當(dāng)要對(duì)文件進(jìn)行寫(xiě)操作時(shí)，才從 image 里把要寫(xiě)的文件復(fù)制到最上面的讀寫(xiě)層進(jìn)行修改。所以無(wú)論有多少個(gè)容器共享同一個(gè) image，所做的寫(xiě)操作都是對(duì)從 image 中復(fù)制后在復(fù)本上進(jìn)行，并不會(huì)修改 image 的源文件，且多個(gè)容器操作同一個(gè)文件，會(huì)在每個(gè)容器的文件系統(tǒng)里生成一個(gè)復(fù)本，每個(gè)容器修改的都是自己的復(fù)本，相互隔離，相互不影響。

2）用時(shí)配置

用時(shí)分配：在鏡像中原本沒(méi)有某個(gè)文件的場(chǎng)景，只有在要新寫(xiě)入一個(gè)文件時(shí)才分配空間，這樣可以提高存儲(chǔ)資源的利用率。比如啟動(dòng)一個(gè)容器，并不會(huì)為這個(gè)容器預(yù)分配一些磁盤(pán)空間，而是當(dāng)有新文件寫(xiě)入時(shí)，才按需分配新空間。

2. 存儲(chǔ)驅(qū)動(dòng)

存儲(chǔ)驅(qū)動(dòng)是指如何對(duì)容器的各層數(shù)據(jù)進(jìn)行管理，已達(dá)到上述需要實(shí)現(xiàn)共享、可讀寫(xiě)的效果。即：容器存儲(chǔ)驅(qū)動(dòng)實(shí)現(xiàn)了容器讀寫(xiě)層數(shù)據(jù)的存儲(chǔ)和管理。常見(jiàn)的存儲(chǔ)驅(qū)動(dòng)：

• AUFS

• OverlayFS

• Devicemapper

• Btrfs

• ZFS

以 AUFS 為例，我們來(lái)講述一下存儲(chǔ)驅(qū)動(dòng)的工作原理：

AUFS 是一種聯(lián)合文件系統(tǒng)（UFS），是文件級(jí)的存儲(chǔ)驅(qū)動(dòng)。

AUFS 是一個(gè)能透明疊加一個(gè)或多個(gè)現(xiàn)有文件系統(tǒng)的層狀文件系統(tǒng)，把多層文件系統(tǒng)合并成單層表示。即：支持將不同目錄掛載到同一個(gè)虛擬文件系統(tǒng)下的文件系統(tǒng)。 
可以一層一層地疊加修改文件，其底層都是只讀的，只有最上層的文件系統(tǒng)是可寫(xiě)的。 
當(dāng)需要修改一個(gè)文件時(shí)，AUFS 創(chuàng)建該文件的一個(gè)副本，使用 CoW 將文件從只讀層復(fù)制到可寫(xiě)層進(jìn)行修改，結(jié)果也保存在可寫(xiě)層。 
在 Docker 中，底下的只讀層就是 image，可寫(xiě)層就是 Container 運(yùn)行時(shí)。

其他各種存儲(chǔ)驅(qū)動(dòng)這里不再細(xì)講，有興趣的同學(xué)可以到網(wǎng)上查詢(xún)資料。

3. Docker 數(shù)據(jù)卷介紹

容器中的應(yīng)用讀寫(xiě)數(shù)據(jù)都是發(fā)生在容器的讀寫(xiě)層，鏡像層+讀寫(xiě)層映射為容器內(nèi)部文件系統(tǒng)、負(fù)責(zé)容器內(nèi)部存儲(chǔ)的底層架構(gòu)。當(dāng)我們需要容器內(nèi)部應(yīng)用和外部存儲(chǔ)進(jìn)行交互時(shí)，需要一個(gè)類(lèi)似于計(jì)算機(jī) U 盤(pán)一樣的外置存儲(chǔ)，容器數(shù)據(jù)卷即提供了這樣的功能。

另一方面：容器本身的存儲(chǔ)數(shù)據(jù)都是臨時(shí)存儲(chǔ)，在容器銷(xiāo)毀的時(shí)候數(shù)據(jù)會(huì)一起刪除。而通過(guò)數(shù)據(jù)卷將外部存儲(chǔ)掛載到容器文件系統(tǒng)，應(yīng)用可以引用外部數(shù)據(jù)，也可以將自己產(chǎn)出的數(shù)據(jù)持久化到數(shù)據(jù)卷中，所以容器數(shù)據(jù)卷是容器進(jìn)行數(shù)據(jù)持久化的實(shí)現(xiàn)方式。

容器存儲(chǔ)組成：只讀層（容器鏡像） + 讀寫(xiě)層 + 外置存儲(chǔ)（數(shù)據(jù)卷）

容器數(shù)據(jù)卷從作用范圍可以分為：?jiǎn)螜C(jī)數(shù)據(jù)卷 和 集群數(shù)據(jù)卷。單機(jī)數(shù)據(jù)卷即為容器服務(wù)在一個(gè)節(jié)點(diǎn)上的數(shù)據(jù)卷掛載能力，docker volume 是單機(jī)數(shù)據(jù)卷的代表實(shí)現(xiàn)；集群數(shù)據(jù)卷則關(guān)注的是集群級(jí)別的數(shù)據(jù)卷編排能力，K8s 數(shù)據(jù)卷則是集群數(shù)據(jù)卷的主要應(yīng)用方式。

Docker Volume 是一個(gè)可供多個(gè)容器使用的目錄，它繞過(guò) UFS，包含以下特性：

• 數(shù)據(jù)卷可以在容器之間共享和重用；

• 相比通過(guò)存儲(chǔ)驅(qū)動(dòng)實(shí)現(xiàn)的可寫(xiě)層，數(shù)據(jù)卷讀寫(xiě)是直接對(duì)外置存儲(chǔ)進(jìn)行讀寫(xiě)，效率更高；

• 對(duì)數(shù)據(jù)卷的更新是對(duì)外置存儲(chǔ)讀寫(xiě)，不會(huì)影響鏡像和容器讀寫(xiě)層；

• 數(shù)據(jù)卷可以一直存在，直到?jīng)]有容器使用。

1）Docker 數(shù)據(jù)卷類(lèi)型

Bind：將主機(jī)目錄/文件直接掛載到容器內(nèi)部。

• 需要使用主機(jī)的上的絕對(duì)路徑，且可以自動(dòng)創(chuàng)建主機(jī)目錄；

• 容器可以修改掛載目錄下的任何文件，是應(yīng)用更具有便捷性，但也帶來(lái)了安全隱患。

Volume：使用第三方數(shù)據(jù)卷的時(shí)候使用這種方式。

• Volume命令行指令：docker volume (create/rm)；

• 是Docker提供的功能，所以在非 docker 環(huán)境下無(wú)法使用；

• 分為命名數(shù)據(jù)卷和匿名數(shù)據(jù)卷，其實(shí)現(xiàn)是一致的，區(qū)別是匿名數(shù)據(jù)卷的名字為隨機(jī)碼；

• 支持?jǐn)?shù)據(jù)卷驅(qū)動(dòng)擴(kuò)展，實(shí)現(xiàn)更多外部存儲(chǔ)類(lèi)型的接入。

Tmpfs：非持久化的卷類(lèi)型，存儲(chǔ)在內(nèi)存中。

數(shù)據(jù)易丟失。

2）Bind 掛載方式語(yǔ)法

-v: src:dst:opts 只支持單機(jī)版。

• Src：表示卷映射源，主機(jī)目錄或文件，需要是絕對(duì)地址；

• Dst：容器內(nèi)目標(biāo)掛載地址；

• Opts：可選，掛載屬性：ro, consistent, delegated, cached, z, Z；

• Consistent, delegated, cached：為mac系統(tǒng)配置共享傳播屬性；

• Z、z：配置主機(jī)目錄的selinux label。

示例：

$ docker run -d --name devtest -v /home:/data:ro,rslave nginx$ docker run -d --name devtest --mount type=bind,source=/home,target=/data,readonly,bind-propagation=rslave nginx$ docker run -d --name devtest -v /home:/data:z nginx

3）Volume 掛載方式語(yǔ)法

-v: src:dst:opts 只支持單機(jī)版。

• Src：表示卷映射源，數(shù)據(jù)卷名、空；

• Dst：容器內(nèi)目標(biāo)目錄；

• Opts：可選，掛載屬性：ro（只讀）。

示例：

$ docker run -d --name devtest -v myvol:/app:ro nginx$ docker run -d --name devtest --mount source=myvol2,target=/app,readonly nginx

4. Docker 數(shù)據(jù)卷使用

Docker 數(shù)據(jù)卷使用方式：

1）Volume 類(lèi)型

• 匿名數(shù)據(jù)卷：docker run –d -v /data3 nginx；

• 會(huì)主機(jī)上默認(rèn)創(chuàng)建目錄：/var/lib/docker/volumes/{volume-id}/_data進(jìn)行映射；

• 命名數(shù)據(jù)卷：docker run –d -v nas1:/data3 nginx；

• 如果當(dāng)前找不到nas1卷，會(huì)創(chuàng)建一個(gè)默認(rèn)類(lèi)型(local)的卷。

2）Bind 方式

docker run -d -v /test:/data nginx 
如果主機(jī)上沒(méi)有/test目錄，則默認(rèn)創(chuàng)建此目錄。

3）數(shù)據(jù)卷容器

數(shù)據(jù)卷容器是一個(gè)運(yùn)行中的容器，其他容器可以繼承此容器中的掛載數(shù)據(jù)卷，則此容器的所有掛載都會(huì)在引用容器中體現(xiàn)。

docker run -d —volumes-from nginx1 -v /test1:/data1 nginx 
繼承所有來(lái)自配置容器的數(shù)據(jù)卷，并包含自己定義的卷。

4）數(shù)據(jù)卷的掛載傳播

Docker volume 支持掛載傳播的配置：Propagation。

• Private：掛載不傳播，源目錄和目標(biāo)目錄中的掛載都不會(huì)在另一方體現(xiàn)；

• Shared：掛載會(huì)在源和目的之間傳播；

• Slave：源對(duì)象的掛載可以傳播到目的對(duì)象，反之不行；

• Rprivate：遞歸 Private，默認(rèn)方式；

• Rshared：遞歸 Shared；

• Rslave：遞歸 Slave。

示例：

$ docker run –d -v /home:/data:shared nginx表示：主機(jī)/home下面掛載的目錄，在容器/data下面可用，反之可行；$ docker run –d -v /home:/data:slave nginx表示：主機(jī)/home下面掛載的目錄，在容器/data下面可用，反之不行；

5）數(shù)據(jù)卷掛載的可見(jiàn)性

Volume 掛載可見(jiàn)性：

• 本地空目錄、鏡像空目錄：無(wú)特殊處理；

• 本地空目錄、鏡像非空目錄：鏡像目錄的內(nèi)容拷貝到主機(jī)；(是拷貝，不是映射；即使容器刪除內(nèi)容也會(huì)保存)；

• 本地非空目錄、鏡像空目錄：本地目錄內(nèi)容映射到容器；

• 本地非空目錄、鏡像非空目錄：本地目錄內(nèi)容映射到容器,容器目錄的內(nèi)容被隱藏。

Bind 掛載可見(jiàn)性：以主機(jī)目錄為準(zhǔn)。

• 本地空目錄、鏡像空目錄：無(wú)特殊處理；

• 本地空目錄、鏡像非空目錄：容器目錄變成空；

• 本地非空目錄、鏡像空目錄：本地目錄內(nèi)容映射到容器；

• 本地非空目錄、鏡像非空目錄：本地目錄內(nèi)容映射到容器，容器目錄的內(nèi)容被隱藏。

5. Docker數(shù)據(jù)卷插件

Docker 數(shù)據(jù)卷實(shí)現(xiàn)了將容器外部存儲(chǔ)掛載到容器文件系統(tǒng)的方式。為了擴(kuò)展容器對(duì)外部存儲(chǔ)類(lèi)型的需求，docker 提出了通過(guò)存儲(chǔ)插件的方式掛載不同類(lèi)型的存儲(chǔ)服務(wù)。擴(kuò)展插件統(tǒng)稱(chēng)為 Volume Driver，可以為每種存儲(chǔ)類(lèi)型開(kāi)發(fā)一種存儲(chǔ)插件。

• 單個(gè)節(jié)點(diǎn)上可以部署多個(gè)存儲(chǔ)插件；

• 一個(gè)存儲(chǔ)插件負(fù)責(zé)一種存儲(chǔ)類(lèi)型的掛載服務(wù)。

Docker Daemon 與 Volume driver 通信方式有：

• Sock文件：linux 下放在/run/docker/plugins 目錄下

• Spec文件：/etc/docker/plugins/convoy.spec 定義

• Json文件：/usr/lib/docker/plugins/infinit.json 定義

實(shí)現(xiàn)接口：

Create, Remove, Mount, Path, Umount, Get, List, Capabilities;

使用示例：

$ docker volume create --driver nas -o diskid="" -o host="10.46.225.247" -o path=”/nas1" -o mode="" --name nas1

Docker Volume Driver 適用在單機(jī)容器環(huán)境或者 swarm 平臺(tái)進(jìn)行數(shù)據(jù)卷管理，隨著 K8s 的流行其使用場(chǎng)景已經(jīng)越來(lái)越少，關(guān)于 VolumeDriver 的詳細(xì)介紹這里不在細(xì)講，有興趣可以參考：  https://docs.docker.com/engine/extend/plugins_volume/

K8s 存儲(chǔ)卷

1. 基礎(chǔ)概念

根據(jù)之前的描述，為了實(shí)現(xiàn)容器數(shù)據(jù)的持久化我們需要使用數(shù)據(jù)卷的功能，在 K8s 編排系統(tǒng)中如何為運(yùn)行的負(fù)載(Pod)定義存儲(chǔ)呢？K8s 是一個(gè)容器編排系統(tǒng)，其關(guān)注的是容器應(yīng)用在整個(gè)集群的管理和部署形式，所以在考慮 K8s 應(yīng)用存儲(chǔ)的時(shí)候就需要從集群角度考慮。K8s 存儲(chǔ)卷定義了在 K8s 系統(tǒng)中應(yīng)用與存儲(chǔ)的關(guān)聯(lián)關(guān)系。其包含以下概念：

1）Volume 數(shù)據(jù)卷

數(shù)據(jù)卷定義了外置存儲(chǔ)的細(xì)節(jié)，并內(nèi)嵌到 Pod 中作為 Pod 的一部分。其實(shí)質(zhì)是外置存儲(chǔ)在 K8s 系統(tǒng)的一個(gè)記錄對(duì)象，當(dāng)負(fù)載需要使用外置存儲(chǔ)的時(shí)候，從數(shù)據(jù)卷中查到相關(guān)信息并進(jìn)行存儲(chǔ)掛載操作。

• 生命周期和 Pod 一致，即 pod 被刪除的時(shí)候數(shù)據(jù)卷也一起消失（注意不是數(shù)據(jù)刪除）；

• 存儲(chǔ)細(xì)節(jié)定義在編排模板中，應(yīng)用編排感知存儲(chǔ)細(xì)節(jié)；

• 一個(gè)負(fù)載（Pod）中可以同時(shí)定義多個(gè) volume，可以是相同類(lèi)型或不同類(lèi)型的存儲(chǔ)；

• Pod 的每個(gè) container 可以引用一個(gè)或多個(gè) volume，不同 container 可以同時(shí)使用相同 volume。

K8S Volume 常用類(lèi)型：

• 本地存儲(chǔ)：如 HostPath、emptyDir，這些存儲(chǔ)卷的特點(diǎn)是，數(shù)據(jù)保存在集群的特定節(jié)點(diǎn)上，并且不能隨著應(yīng)用飄逸，節(jié)點(diǎn)宕機(jī)時(shí)數(shù)據(jù)即不再可用；

• 網(wǎng)絡(luò)存儲(chǔ)：Ceph、Glusterfs、NFS、Iscsi 等類(lèi)型，這些存儲(chǔ)卷的特點(diǎn)是數(shù)據(jù)不在集群的某個(gè)節(jié)點(diǎn)上，而是在遠(yuǎn)端的存儲(chǔ)服務(wù)上，使用存儲(chǔ)卷時(shí)需要將存儲(chǔ)服務(wù)掛載到本地使用；

• Secret/ConfigMap：這些存儲(chǔ)卷類(lèi)型，其數(shù)據(jù)是集群的一些對(duì)象信息，并不屬于某個(gè)節(jié)點(diǎn)，使用時(shí)將對(duì)象數(shù)據(jù)以卷的形式掛載到節(jié)點(diǎn)上供應(yīng)用使用；

• CSI/Flexvolume：這是兩種數(shù)據(jù)卷擴(kuò)容方式，可以理解為抽象的數(shù)據(jù)卷類(lèi)型。每種擴(kuò)展方式都可再細(xì)化成不同的存儲(chǔ)類(lèi)型；

• PVC：一種數(shù)據(jù)卷定義方式，將數(shù)據(jù)卷抽象成一個(gè)獨(dú)立于 pod 的對(duì)象，這個(gè)對(duì)象定義（關(guān)聯(lián)）的存儲(chǔ)信息即存儲(chǔ)卷對(duì)應(yīng)的真正存儲(chǔ)信息，供 K8s 負(fù)載掛載使用。

一些 volume 模板示例如下：

volumes: - name: hostpath    hostPath:      path: /data      type: Directory---  volumes: - name: disk-ssd    persistentVolumeClaim:      claimName: disk-ssd-web-0 - name: default-token-krggw    secret:      defaultMode: 420      secretName: default-token-krggw---  volumes: - name: "oss1"      flexVolume:        driver: "alicloud/oss"        options:          bucket: "docker"          url: "oss-cn-hangzhou.aliyuncs.com"

2）PVC和PV

• K8s 存儲(chǔ)卷是一個(gè)集群級(jí)別的概念，其對(duì)象作用范圍是整個(gè) K8s 集群，而不是而一個(gè)節(jié)點(diǎn)；

• K8s 存儲(chǔ)卷包含一些對(duì)象（PVC、PV、SC），這些對(duì)象和應(yīng)用負(fù)載（Pod）是獨(dú)立，通過(guò)編排模板進(jìn)行關(guān)聯(lián)；

• K8s 存儲(chǔ)卷可以有自己的獨(dú)立生命周期，不依附于 Pod。

PVC 是 PersistentVolumeClaim 的縮寫(xiě)，譯為存儲(chǔ)聲明；PVC 是在 K8s 中一種抽象的存儲(chǔ)卷類(lèi)型，代表了某個(gè)具體類(lèi)型存儲(chǔ)的數(shù)據(jù)卷表達(dá)。其設(shè)計(jì)意圖是：存儲(chǔ)與應(yīng)用編排分離，將存儲(chǔ)細(xì)節(jié)抽象出來(lái)并實(shí)現(xiàn)存儲(chǔ)的編排（存儲(chǔ)卷）。這樣 K8s 中存儲(chǔ)卷對(duì)象獨(dú)立于應(yīng)用編排而單獨(dú)存在，在編排層面使應(yīng)用和存儲(chǔ)解耦。

PV 是 PersistentVolume 的縮寫(xiě)，譯為持久化存儲(chǔ)卷；PV 在 K8s 中代表一個(gè)具體存儲(chǔ)類(lèi)型的卷，其對(duì)象中定義了具體存儲(chǔ)類(lèi)型和卷參數(shù)。即目標(biāo)存儲(chǔ)服務(wù)所有相關(guān)的信息都保存在 PV 中，K8s 引用 PV 中的存儲(chǔ)信息執(zhí)行掛載操作。

應(yīng)用負(fù)載、PVC、PV 的關(guān)聯(lián)關(guān)系為：

從實(shí)現(xiàn)上看，只要有了 PV 既可以實(shí)現(xiàn)存儲(chǔ)和應(yīng)用的編排分離，也能實(shí)現(xiàn)數(shù)據(jù)卷的掛載，為何要用 PVC + PV 兩個(gè)對(duì)象呢？K8s 這樣設(shè)計(jì)是從應(yīng)用角度對(duì)存儲(chǔ)卷進(jìn)行二次抽象；由于 PV 描述的是對(duì)具體存儲(chǔ)類(lèi)型，需要定義詳細(xì)的存儲(chǔ)信息，而應(yīng)用層用戶(hù)在消費(fèi)存儲(chǔ)服務(wù)的時(shí)候往往不希望對(duì)底層細(xì)節(jié)知道的太多，讓?xiě)?yīng)用編排層面來(lái)定義具體的存儲(chǔ)服務(wù)不夠友好。這時(shí)對(duì)存儲(chǔ)服務(wù)再次進(jìn)行抽象，只把用戶(hù)關(guān)系的參數(shù)提煉出來(lái)，用 PVC 來(lái)抽象更底層的 PV。所以 PVC、PV 關(guān)注的對(duì)象不一樣，PVC 關(guān)注用戶(hù)對(duì)存儲(chǔ)需求，給用戶(hù)提供統(tǒng)一的存儲(chǔ)定義方式；而 PV 關(guān)注的是存儲(chǔ)細(xì)節(jié)，可以定義具體存儲(chǔ)類(lèi)型、存儲(chǔ)掛載使用的詳細(xì)參數(shù)等。

使用時(shí)應(yīng)用層會(huì)聲明一個(gè)對(duì)存儲(chǔ)的需求（PVC），而 K8s 會(huì)通過(guò)最佳匹配的方式選擇一個(gè)滿(mǎn)足 PVC 需求的 PV，并與之綁定。所以從職責(zé)上 PVC 是應(yīng)用所需要的存儲(chǔ)對(duì)象，屬于應(yīng)用作用域（和應(yīng)用處于一個(gè)名詞空間）；PV 是存儲(chǔ)平面的存儲(chǔ)對(duì)象，屬于整個(gè)存儲(chǔ)域（不屬于某個(gè)名詞空間）；

下面給出 PVC、PV 的一些屬性：

• PVC 和 PV 總是成對(duì)出現(xiàn)的，PVC 必須與 PV 綁定后才能被應(yīng)用（Pod）消費(fèi)；

• PVC 和 PV 是一一綁定關(guān)系，不存在一個(gè) PV 被多個(gè) PVC 綁定，或者一個(gè) PVC 綁定多個(gè) PV 的情況；

• PVC 是應(yīng)用層面的存儲(chǔ)概念，是屬于具體的名詞空間的；

• PV 是存儲(chǔ)層面的存儲(chǔ)概念，是集群級(jí)別的，不屬于某個(gè)名詞空間；PV 常由專(zhuān)門(mén)的存儲(chǔ)運(yùn)維人員負(fù)責(zé)管理；

• 消費(fèi)關(guān)系上：Pod 消費(fèi) PVC，PVC 消費(fèi) PV，而 PV 定義了具體的存儲(chǔ)介質(zhì)。

3）PVC 詳細(xì)定義

PVC 定義的模板如下：

apiVersion: v1kind: PersistentVolumeClaimmetadata:  name: disk-ssd-web-0spec:  accessModes: - ReadWriteOnce  resources:    requests:      storage: 20Gi  storageClassName: alicloud-disk-available  volumeMode: Filesystem

PVC 定義的存儲(chǔ)接口包括：存儲(chǔ)的讀寫(xiě)模式、資源容量、卷模式等；主要參數(shù)說(shuō)明如下：

accessModes：存儲(chǔ)卷的訪(fǎng)問(wèn)模式，支持：ReadWriteOnce、ReadWriteMany、ReadOnlyMany 三種模式。

• ReadWriteOnce 表示 pvc 只能同時(shí)被一個(gè) pod 以讀寫(xiě)方式消費(fèi)；

• ReadWriteMany 可以同時(shí)被多個(gè) pod 以讀寫(xiě)方式消費(fèi)；

• ReadOnlyMany 表示可以同時(shí)被多個(gè) pod 以只讀方式消費(fèi)；

注意：這里定義的訪(fǎng)問(wèn)模式只是編排層面的聲明，具體應(yīng)用在讀寫(xiě)存儲(chǔ)文件的時(shí)候是否可讀可寫(xiě)，需要具體的存儲(chǔ)插件實(shí)現(xiàn)確定。

storage：定義此 PVC 對(duì)象期望提供的存儲(chǔ)容量，同樣此處的數(shù)據(jù)大小也只是編排聲明的值，具體存儲(chǔ)容量要看底層存儲(chǔ)服務(wù)類(lèi)型。

volumeMode：表示存儲(chǔ)卷掛載模式，支持 FileSystem、Block 兩種模式；

FileSystem：將數(shù)據(jù)卷掛載成文件系統(tǒng)的方式供應(yīng)用使用； 
Block：將數(shù)據(jù)卷掛載成塊設(shè)備的形式供應(yīng)用使用。

4）PV 詳細(xì)定義

下面為云盤(pán)數(shù)據(jù)卷 PV 對(duì)象的編排示例：

apiVersion: v1kind: PersistentVolumemetadata:  labels:    failure-domain.beta.kubernetes.io/region: cn-shenzhen    failure-domain.beta.kubernetes.io/zone: cn-shenzhen-e  name: d-wz9g2j5qbo37r2lamkg4spec:  accessModes: - ReadWriteOnce  capacity:    storage: 30Gi  flexVolume:    driver: alicloud/disk    fsType: ext4    options: VolumeId: d-wz9g2j5qbo37r2lamkg4  persistentVolumeReclaimPolicy: Delete  storageClassName: alicloud-disk-available  volumeMode: Filesystem

• accessModes：存儲(chǔ)卷的訪(fǎng)問(wèn)模式，支持：ReadWriteOnce、ReadWriteMany、ReadOnlyMany 三種模式；具體含義同 PVC 字段；

• capacity：定義存儲(chǔ)卷容量；

• persistentVolumeReclaimPolicy：定義回收策略，即刪除 pvc 的時(shí)候如何處理 PV；支持 Delete、Retain 兩種類(lèi)型，動(dòng)態(tài)數(shù)據(jù)卷部分會(huì)詳細(xì)說(shuō)明此參數(shù)；

• storageClassName：表示存儲(chǔ)卷的使用的存儲(chǔ)類(lèi)名字，動(dòng)態(tài)數(shù)據(jù)卷部分會(huì)詳細(xì)說(shuō)明此參數(shù)；

• volumeMode：同 PVC 中的 volumeMode 定義；

• Flexvolume：此字段表示具體的存儲(chǔ)類(lèi)型，這里 Flexvolume 為一種抽象的存儲(chǔ)類(lèi)型，并在 flexvolume 的子配置項(xiàng)中定義了具體的存儲(chǔ)類(lèi)型、存儲(chǔ)參數(shù)。

5）PVC/PV 綁定

PVC 只有綁定了 PV 之后才能被 Pod 使用，而 PVC 綁定 PV 的過(guò)程即是消費(fèi) PV 的過(guò)程，這個(gè)過(guò)程是有一定規(guī)則的，下面規(guī)則都滿(mǎn)足的 PV 才能被 PVC 綁定：

• VolumeMode：被消費(fèi) PV 的 VolumeMode 需要和 PVC 一致；

• AccessMode：被消費(fèi) PV 的 AccessMode 需要和 PVC 一致；

• StorageClassName：如果 PVC 定義了此參數(shù)，PV 必須有相關(guān)的參數(shù)定義才能進(jìn)行綁定；

• LabelSelector：通過(guò) label 匹配的方式從 PV 列表中選擇合適的 PV 綁定；

• storage：被消費(fèi) PV 的 capacity 必須大于或者等于 PVC 的存儲(chǔ)容量需求才能被綁定。

滿(mǎn)足上述所有需要的 PV 才可以被 PVC 綁定。

如果同時(shí)有多個(gè) PV 滿(mǎn)足需求，則需要從 PV 中選擇一個(gè)更合適的進(jìn)行綁定；通常選擇容量最小的，如果容量最小的也有多個(gè)，則隨機(jī)選擇。 
如果沒(méi)有滿(mǎn)足上述需求的 PV 存儲(chǔ)，則 PVC 會(huì)處于 Pending 狀態(tài)，等待有合適的 PV 出現(xiàn)了再進(jìn)行綁定。

2. 靜態(tài)、動(dòng)態(tài)存儲(chǔ)卷

從上面的討論我們了解到，PVC 是針對(duì)應(yīng)用服務(wù)對(duì)存儲(chǔ)的二次抽象，具有簡(jiǎn)潔的存儲(chǔ)定義接口。而 PV 是具有繁瑣存儲(chǔ)細(xì)節(jié)的存儲(chǔ)抽象，一般有專(zhuān)門(mén)的集群管理人員定義、維護(hù)。

根據(jù) PV 的創(chuàng)建方式可以將存儲(chǔ)卷分為動(dòng)態(tài)存儲(chǔ)和靜態(tài)存儲(chǔ)卷：

• 靜態(tài)存儲(chǔ)卷：由管理員創(chuàng)建的 PV

• 動(dòng)態(tài)存儲(chǔ)卷：由 Provisioner 插件創(chuàng)建的 PV

1）靜態(tài)存儲(chǔ)卷

一般先由集群管理員分析集群中存儲(chǔ)需求，并預(yù)先分配一些存儲(chǔ)介質(zhì)，同時(shí)創(chuàng)建對(duì)應(yīng)的 PV 對(duì)象，創(chuàng)建好的 PV 對(duì)象等待 PVC 來(lái)消費(fèi)。如果負(fù)載中定義了 PVC 需求，K8s 會(huì)通過(guò)相關(guān)規(guī)則實(shí)現(xiàn) PVC 和匹配的 PV 進(jìn)行綁定，這樣就實(shí)現(xiàn)了應(yīng)用對(duì)存儲(chǔ)服務(wù)的訪(fǎng)問(wèn)能力。

2）動(dòng)態(tài)存儲(chǔ)卷

由集群管理員配置好后端的存儲(chǔ)池，并創(chuàng)建相應(yīng)的模板（storageclass），等到有 PVC 需要消費(fèi) PV 的時(shí)候，根據(jù) PVC 定義的需求，并參考 storageclass 的存儲(chǔ)細(xì)節(jié)，由 Provisioner 插件動(dòng)態(tài)創(chuàng)建一個(gè) PV。

兩種卷的比較：

• 動(dòng)態(tài)存儲(chǔ)卷和靜態(tài)存儲(chǔ)卷最終的效果都是：Pod -> PVC -> PV 的使用鏈路，且對(duì)象的具體模板定義都是一致的；

• 動(dòng)態(tài)存儲(chǔ)卷和靜態(tài)存儲(chǔ)卷區(qū)別是：動(dòng)態(tài)卷是插件自動(dòng)創(chuàng)建 PV，而靜態(tài)卷是集群管理員手動(dòng)創(chuàng)建 PV。

提供動(dòng)態(tài)存儲(chǔ)卷的優(yōu)勢(shì)：

• 動(dòng)態(tài)卷讓 K8s 實(shí)現(xiàn)了 PV 的自動(dòng)化生命周期管理，PV 的創(chuàng)建、刪除都通過(guò) Provisioner 完成；

• 自動(dòng)化創(chuàng)建 PV 對(duì)象，減少了配置復(fù)雜度和系統(tǒng)管理員的工作量；

• 動(dòng)態(tài)卷可以實(shí)現(xiàn) PVC 對(duì)存儲(chǔ)的需求容量和 Provision 出來(lái)的 PV 容量一致，實(shí)現(xiàn)存儲(chǔ)容量規(guī)劃最優(yōu)。

3）動(dòng)態(tài)卷的實(shí)現(xiàn)流程

當(dāng)用戶(hù)聲明一個(gè) PVC 時(shí)，如果在 PVC 中添加了 StorageClassName 字段，其意圖為：當(dāng) PVC 在集群中找不到匹配的 PV 時(shí)，會(huì)根據(jù) StorageClassName 的定義觸發(fā)相應(yīng)的 Provisioner 插件創(chuàng)建合適的 PV 供綁定，即創(chuàng)建動(dòng)態(tài)數(shù)據(jù)卷；動(dòng)態(tài)數(shù)據(jù)卷時(shí)由 Provisioner 插件創(chuàng)建的，并通過(guò) StorageClassName 與 PVC 進(jìn)行關(guān)聯(lián)。

StorageClass 可譯為存儲(chǔ)類(lèi)，表示為一個(gè)創(chuàng)建 PV 存儲(chǔ)卷的模板；在 PVC 觸發(fā)自動(dòng)創(chuàng)建PV的過(guò)程中，即使用 StorageClass 對(duì)象中的內(nèi)容進(jìn)行創(chuàng)建。其內(nèi)容包括：目標(biāo) Provisioner 名字，創(chuàng)建 PV 的詳細(xì)參數(shù)，回收模式等配置。

StorageClasss 模板定義如下：

apiVersion: storage.k8s.io/v1kind: StorageClassmetadata:  name: alicloud-disk-topologyparameters:  type: cloud_ssdprovisioner: diskplugin.csi.alibabacloud.comreclaimPolicy: DeleteallowVolumeExpansion: truevolumeBindingMode: WaitForFirstConsumer

• provisioner：為一個(gè)注冊(cè)插件的名字，此插件實(shí)現(xiàn)了創(chuàng)建 PV 的功能；一個(gè) StorageClass 只能定義一個(gè)Provisioner；

• parameters：表示創(chuàng)建數(shù)據(jù)卷的具體參數(shù)；例如這里表示創(chuàng)建一個(gè) SSD 類(lèi)型的云盤(pán)；

• reclaimPolicy：用來(lái)指定創(chuàng)建 PV 的 persistentVolumeReclaimPolicy 字段值，支持 Delete/Retain；Delete 表示動(dòng)態(tài)創(chuàng)建的 PV，在銷(xiāo)毀的時(shí)候也會(huì)自動(dòng)銷(xiāo)毀；Retain 表示動(dòng)態(tài)創(chuàng)建的 PV，不會(huì)自動(dòng)銷(xiāo)毀，而是由管理員來(lái)處理；

• allowVolumeExpansion：定義由此存儲(chǔ)類(lèi)創(chuàng)建的 PV 是否運(yùn)行動(dòng)態(tài)擴(kuò)容，默認(rèn)為 false；是否能動(dòng)態(tài)擴(kuò)容是有底層存儲(chǔ)插件來(lái)實(shí)現(xiàn)的，這里只是一個(gè)開(kāi)關(guān)；

• volumeBindingMode：表示動(dòng)態(tài)創(chuàng)建 PV 的時(shí)間，支持 Immediate/WaitForFirstConsumer；分別表示立即創(chuàng)建和延遲創(chuàng)建。

用戶(hù)創(chuàng)建一個(gè) PVC 聲明時(shí)，會(huì)在集群尋找合適的 PV 進(jìn)行綁定，如果沒(méi)有合適的 PV 與之綁定，則觸發(fā)下面流程：

• Volume Provisioner 會(huì) watch 到這個(gè) PVC 的存在，若這個(gè) PVC 定義了 StorageClassName，且 StorageClass 對(duì)象中定義的 Provisioner 插件是自己，Provisioner 會(huì)觸發(fā)創(chuàng)建 PV 的流程；

• Provisioner 根據(jù) PVC 定義的參數(shù)（Size、VolumeMode、AccessModes）以及 StorageClass 定義的參數(shù)（ReclaimPolicy、Parameters）執(zhí)行 PV 創(chuàng)建；

• Provisioner 會(huì)在存儲(chǔ)介質(zhì)端創(chuàng)建數(shù)據(jù)卷（通過(guò) API 調(diào)用，或者其他方式），完成后會(huì)創(chuàng)建 PV 對(duì)象；

• PV 創(chuàng)建完成后，實(shí)現(xiàn)與 PVC 的綁定；以滿(mǎn)足后續(xù)的 Pod 啟動(dòng)流程。

4）延遲綁定動(dòng)態(tài)數(shù)據(jù)卷

某種存儲(chǔ)（阿里云云盤(pán)）在掛載屬性上有所限制，只能將相同可用區(qū)的數(shù)據(jù)卷和 Node 節(jié)點(diǎn)進(jìn)行掛載，不在同一個(gè)可用區(qū)不可以?huà)燧d。這種類(lèi)型的存儲(chǔ)卷通常遇到如下問(wèn)題：

• 創(chuàng)建了 A 可用區(qū)的數(shù)據(jù)卷，但是 A 可用區(qū)的節(jié)點(diǎn)資源已經(jīng)耗光，導(dǎo)致 Pod 啟動(dòng)無(wú)法完成掛載；

• 集群管理員在規(guī)劃 PVC、PV 的時(shí)候不能確定在哪些可用區(qū)創(chuàng)建多個(gè) PV 來(lái)備用。

StorageClass 中的 volumeBindingMode 字段正是用來(lái)解決此問(wèn)題，如果將 volumeBindingMode 配置為 WaitForFirstConsumer 值，則表示 Provisioner 在收到 PVC Pending 的時(shí)候不會(huì)立即進(jìn)行數(shù)據(jù)卷創(chuàng)建，而是等待這個(gè) PVC 被 Pod 消費(fèi)的時(shí)候才執(zhí)行創(chuàng)建流程。

其實(shí)現(xiàn)原理是：

• Provisioner 在收到 PVC Pending 狀態(tài)的時(shí)候不會(huì)立即進(jìn)行數(shù)據(jù)卷創(chuàng)建，而是等待這個(gè) PVC 被 Pod 消費(fèi)；

• 如果有 Pod 消費(fèi)此 PVC，調(diào)度器發(fā)現(xiàn) PVC 是延遲綁定，則 pv 繼續(xù)完成調(diào)度功能（后續(xù)會(huì)詳細(xì)講解存儲(chǔ)調(diào)度）；且調(diào)度器會(huì)將調(diào)度結(jié)果 patch 到 PVC 的 metadata 中；

• 當(dāng) Provisioner 發(fā)現(xiàn) PVC 中寫(xiě)入了調(diào)度信息時(shí)，會(huì)根據(jù)調(diào)度信息獲取創(chuàng)建目標(biāo)數(shù)據(jù)卷的位置信息（zone、Node），并觸發(fā) PV 的創(chuàng)建流程。

通過(guò)上述流程可見(jiàn)：延遲綁定會(huì)先讓?xiě)?yīng)用負(fù)載進(jìn)行調(diào)度（確定有充足的資源供 pod 使用），然后再觸發(fā)動(dòng)態(tài)卷的創(chuàng)建流程，這樣就避免了數(shù)據(jù)卷所在可用區(qū)沒(méi)有資源的問(wèn)題，也避免了存儲(chǔ)預(yù)規(guī)劃的不準(zhǔn)確性問(wèn)題。

在多可用區(qū)集群環(huán)境中，更推薦使用延遲綁定的動(dòng)態(tài)卷方案，目前阿里云 ACK 集群已經(jīng)支持上述配置方案。

3. 使用示例

下面給出一個(gè) pod 消費(fèi) PVC、PV 的例子：

apiVersion: v1kind: PersistentVolumeClaimmetadata:  name: nas-pvcspec:  accessModes: - ReadWriteOnce  resources:    requests:      storage: 50Gi  selector:    matchLabels:      alicloud-pvname: nas-csi-pv---apiVersion: v1kind: PersistentVolumemetadata:  name: nas-csi-pv  labels:    alicloud-pvname: nas-csi-pvspec:  capacity:    storage: 50Gi  accessModes: - ReadWriteOnce  persistentVolumeReclaimPolicy: Retain  flexVolume:    driver: "alicloud/nas"    options:      server: "***-42ad.cn-shenzhen.extreme.nas.aliyuncs.com"      path: "/share/nas"---apiVersion: apps/v1kind: Deploymentmetadata:  name: deployment-nas  labels:    app: nginxspec:  selector:    matchLabels:      app: nginx template:    metadata:      labels:        app: nginx    spec:      containers: - name: nginx1        image: nginx:1.8 - name: nginx2        image: nginx:1.7.9        volumeMounts: - name: nas-pvc            mountPath: "/data"      volumes: - name: nas-pvc          persistentVolumeClaim:            claimName: nas-pvc

模板解析：

• 此應(yīng)用為 Deployment 方式編排的一個(gè) Nginx 服務(wù)，每個(gè) pod 包含 2 個(gè)容器：nginx1、nginx2；

• 模板中定義了 Volumes 字段，說(shuō)明期望掛載數(shù)據(jù)卷給應(yīng)用使用，此例中使用了 PVC 這種數(shù)據(jù)卷定義方式；

• 應(yīng)用內(nèi)部：將數(shù)據(jù)卷 nas-pvc 掛載到 nginx2容器的 /data 目錄上；nginx1 容器并沒(méi)有掛載；

• PVC（nas-pvc）定義為一個(gè)不小于 50G 容量、讀寫(xiě)方式為 ReadWriteOnce 的存儲(chǔ)卷需求，且對(duì) PV 有 Label 設(shè)置的需求；

• PV（nas-csi-pv）定義為一個(gè)容量為 50G、讀寫(xiě)方式為 ReadWriteOnce、回收模式為 Retain、類(lèi)型為 Flexvolume 抽象類(lèi)型的存儲(chǔ)卷，且具有 Label 配置；

根據(jù) PVC、PV 綁定的邏輯，此 PV 符合 PVC 消費(fèi)要求，則 PVC 會(huì)和此 PV 進(jìn)行綁定，并供 pod 掛載使用。

上述內(nèi)容就是云原生存儲(chǔ)中的容器存儲(chǔ)與 K8s 存儲(chǔ)卷怎么理解，你們學(xué)到知識(shí)或技能了嗎？如果還想學(xué)到更多技能或者豐富自己的知識(shí)儲(chǔ)備，歡迎關(guān)注億速云行業(yè)資訊頻道。