作者 | 闞俊寶 阿里云技術(shù)專家

導(dǎo)讀：云原生存儲詳解系列文章將從云原生存儲服務(wù)的概念、特點(diǎn)、需求、原理、使用及案例等方面，和大家一起探討云原生存儲技術(shù)新的機(jī)遇與挑戰(zhàn)。本文為該系列文章的第二篇，會(huì)對容器存儲的相關(guān)概念進(jìn)行講述，歡迎大家在留言區(qū)參與討論。

相關(guān)文章推薦：

云原生存儲詳解：云原生應(yīng)用的基石
云原生存儲詳解：容器存儲與 K8s 存儲卷

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

• Docker 存儲卷：容器服務(wù)在單節(jié)點(diǎn)的存儲組織形式，關(guān)注數(shù)據(jù)存儲、容器運(yùn)行時(shí)的相關(guān)技術(shù)；
• K8s 存儲卷：關(guān)注容器集群的存儲編排，從應(yīng)用使用存儲的角度關(guān)注存儲服務(wù)。

Docker 存儲

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

1. 容器讀寫層

為了提高節(jié)點(diǎn)存儲的使用效率，容器不光在不同運(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ù)，容器鏡像每一層都是只讀的。而通過實(shí)踐我們得知，使用鏡像啟動(dòng)一個(gè)容器的時(shí)候，其實(shí)是可以在容器里隨意讀寫的，這是如何實(shí)現(xiàn)的呢？

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

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

鏡像存儲層說明如下：

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

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

所以兩個(gè)鏡像共享了 Layer 3、5 兩個(gè)鏡像層；

容器存儲說明：

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

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

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

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

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

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

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

2）用時(shí)配置

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

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

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

• AUFS
• OverlayFS
• Devicemapper
• Btrfs
• ZFS

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

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

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

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

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

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

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

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

容器數(shù)據(jù)卷從作用范圍可以分為：單機(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)注的是集群級別的數(shù)據(jù)卷編排能力，K8s 數(shù)據(jù)卷則是集群數(shù)據(jù)卷的主要應(yīng)用方式。

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

• 數(shù)據(jù)卷可以在容器之間共享和重用；
• 相比通過存儲驅(qū)動(dòng)實(shí)現(xiàn)的可寫層，數(shù)據(jù)卷讀寫是直接對外置存儲進(jìn)行讀寫，效率更高；
• 對數(shù)據(jù)卷的更新是對外置存儲讀寫，不會(huì)影響鏡像和容器讀寫層；
• 數(shù)據(jù)卷可以一直存在，直到?jīng)]有容器使用。

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

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

• 需要使用主機(jī)的上的絕對路徑，且可以自動(dòng)創(chuàng)建主機(jī)目錄；
• 容器可以修改掛載目錄下的任何文件，是應(yīng)用更具有便捷性，但也帶來了安全隱患。

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

• Volume命令行指令：docker volume (create/rm)；
• 是Docker提供的功能，所以在非 docker 環(huán)境下無法使用；
• 分為命名數(shù)據(jù)卷和匿名數(shù)據(jù)卷，其實(shí)現(xiàn)是一致的，區(qū)別是匿名數(shù)據(jù)卷的名字為隨機(jī)碼；
• 支持?jǐn)?shù)據(jù)卷驅(qū)動(dòng)擴(kuò)展，實(shí)現(xiàn)更多外部存儲類型的接入。

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

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

2）Bind 掛載方式語法

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

• Src：表示卷映射源，主機(jī)目錄或文件，需要是絕對地址；
• 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 掛載方式語法

-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 類型

• 匿名數(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)類型(local)的卷。

2）Bind 方式

docker run -d -v /test:/data nginx
如果主機(jī)上沒有/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
繼承所有來自配置容器的數(shù)據(jù)卷，并包含自己定義的卷。

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

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

• Private：掛載不傳播，源目錄和目標(biāo)目錄中的掛載都不會(huì)在另一方體現(xiàn)；
• Shared：掛載會(huì)在源和目的之間傳播；
• Slave：源對象的掛載可以傳播到目的對象，反之不行；
• 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ù)卷掛載的可見性

Volume 掛載可見性：

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

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

• 本地空目錄、鏡像空目錄：無特殊處理；
• 本地空目錄、鏡像非空目錄：容器目錄變成空；
• 本地非空目錄、鏡像空目錄：本地目錄內(nèi)容映射到容器；
• 本地非空目錄、鏡像非空目錄：本地目錄內(nèi)容映射到容器，容器目錄的內(nèi)容被隱藏。

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

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

• 單個(gè)節(jié)點(diǎn)上可以部署多個(gè)存儲插件；
• 一個(gè)存儲插件負(fù)責(zé)一種存儲類型的掛載服務(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 平臺進(jìn)行數(shù)據(jù)卷管理，隨著 K8s 的流行其使用場景已經(jīng)越來越少，關(guān)于 VolumeDriver 的詳細(xì)介紹這里不在細(xì)講，有興趣可以參考：https://docs.docker.com/engine/extend/plugins_volume/

K8s 存儲卷

1. 基礎(chǔ)概念

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

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

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

• 生命周期和 Pod 一致，即 pod 被刪除的時(shí)候數(shù)據(jù)卷也一起消失（注意不是數(shù)據(jù)刪除）；
• 存儲細(xì)節(jié)定義在編排模板中，應(yīng)用編排感知存儲細(xì)節(jié)；
• 一個(gè)負(fù)載（Pod）中可以同時(shí)定義多個(gè) volume，可以是相同類型或不同類型的存儲；
• Pod 的每個(gè) container 可以引用一個(gè)或多個(gè) volume，不同 container 可以同時(shí)使用相同 volume。

K8S Volume 常用類型：

• 本地存儲：如 HostPath、emptyDir，這些存儲卷的特點(diǎn)是，數(shù)據(jù)保存在集群的特定節(jié)點(diǎn)上，并且不能隨著應(yīng)用飄逸，節(jié)點(diǎn)宕機(jī)時(shí)數(shù)據(jù)即不再可用；
• 網(wǎng)絡(luò)存儲：Ceph、Glusterfs、NFS、Iscsi 等類型，這些存儲卷的特點(diǎn)是數(shù)據(jù)不在集群的某個(gè)節(jié)點(diǎn)上，而是在遠(yuǎn)端的存儲服務(wù)上，使用存儲卷時(shí)需要將存儲服務(wù)掛載到本地使用；
• Secret/ConfigMap：這些存儲卷類型，其數(shù)據(jù)是集群的一些對象信息，并不屬于某個(gè)節(jié)點(diǎn)，使用時(shí)將對象數(shù)據(jù)以卷的形式掛載到節(jié)點(diǎn)上供應(yīng)用使用；
• CSI/Flexvolume：這是兩種數(shù)據(jù)卷擴(kuò)容方式，可以理解為抽象的數(shù)據(jù)卷類型。每種擴(kuò)展方式都可再細(xì)化成不同的存儲類型；
• PVC：一種數(shù)據(jù)卷定義方式，將數(shù)據(jù)卷抽象成一個(gè)獨(dú)立于 pod 的對象，這個(gè)對象定義（關(guān)聯(lián)）的存儲信息即存儲卷對應(yīng)的真正存儲信息，供 K8s 負(fù)載掛載使用。

一些 volume 模板示例如下：

volumes:- name: hostpathhostPath:path: /datatype: Directory ---volumes:- name: disk-ssdpersistentVolumeClaim:claimName: disk-ssd-web-0- name: default-token-krggwsecret:defaultMode: 420secretName: default-token-krggw ---volumes:- name: "oss1"flexVolume:driver: "alicloud/oss"options:bucket: "docker"url: "oss-cn-hangzhou.aliyuncs.com"

2）PVC和PV

• K8s 存儲卷是一個(gè)集群級別的概念，其對象作用范圍是整個(gè) K8s 集群，而不是而一個(gè)節(jié)點(diǎn)；
• K8s 存儲卷包含一些對象（PVC、PV、SC），這些對象和應(yīng)用負(fù)載（Pod）是獨(dú)立，通過編排模板進(jìn)行關(guān)聯(lián)；
• K8s 存儲卷可以有自己的獨(dú)立生命周期，不依附于 Pod。

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

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

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

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

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

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

• PVC 和 PV 總是成對出現(xiàn)的，PVC 必須與 PV 綁定后才能被應(yīng)用（Pod）消費(fèi)；
• PVC 和 PV 是一一綁定關(guān)系，不存在一個(gè) PV 被多個(gè) PVC 綁定，或者一個(gè) PVC 綁定多個(gè) PV 的情況；
• PVC 是應(yīng)用層面的存儲概念，是屬于具體的名詞空間的；
• PV 是存儲層面的存儲概念，是集群級別的，不屬于某個(gè)名詞空間；PV 常由專門的存儲運(yùn)維人員負(fù)責(zé)管理；
• 消費(fèi)關(guān)系上：Pod 消費(fèi) PVC，PVC 消費(fèi) PV，而 PV 定義了具體的存儲介質(zhì)。

3）PVC 詳細(xì)定義

PVC 定義的模板如下：

apiVersion: v1 kind: PersistentVolumeClaim metadata:name: disk-ssd-web-0 spec:accessModes:- ReadWriteOnceresources:requests:storage: 20GistorageClassName: alicloud-disk-availablevolumeMode: Filesystem

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

accessModes：存儲卷的訪問模式，支持：ReadWriteOnce、ReadWriteMany、ReadOnlyMany 三種模式。

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

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

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

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

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

4）PV 詳細(xì)定義

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

apiVersion: v1 kind: PersistentVolume metadata:labels:failure-domain.beta.kubernetes.io/region: cn-shenzhenfailure-domain.beta.kubernetes.io/zone: cn-shenzhen-ename: d-wz9g2j5qbo37r2lamkg4 spec:accessModes:- ReadWriteOncecapacity:storage: 30GiflexVolume:driver: alicloud/diskfsType: ext4options:VolumeId: d-wz9g2j5qbo37r2lamkg4persistentVolumeReclaimPolicy: DeletestorageClassName: alicloud-disk-availablevolumeMode: Filesystem

• accessModes：存儲卷的訪問模式，支持：ReadWriteOnce、ReadWriteMany、ReadOnlyMany 三種模式；具體含義同 PVC 字段；
• capacity：定義存儲卷容量；
• persistentVolumeReclaimPolicy：定義回收策略，即刪除 pvc 的時(shí)候如何處理 PV；支持 Delete、Retain 兩種類型，動(dòng)態(tài)數(shù)據(jù)卷部分會(huì)詳細(xì)說明此參數(shù)；
• storageClassName：表示存儲卷的使用的存儲類名字，動(dòng)態(tài)數(shù)據(jù)卷部分會(huì)詳細(xì)說明此參數(shù)；
• volumeMode：同 PVC 中的 volumeMode 定義；
• Flexvolume：此字段表示具體的存儲類型，這里 Flexvolume 為一種抽象的存儲類型，并在 flexvolume 的子配置項(xiàng)中定義了具體的存儲類型、存儲參數(shù)。

5）PVC/PV 綁定

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

• VolumeMode：被消費(fèi) PV 的 VolumeMode 需要和 PVC 一致；
• AccessMode：被消費(fèi) PV 的 AccessMode 需要和 PVC 一致；
• StorageClassName：如果 PVC 定義了此參數(shù)，PV 必須有相關(guān)的參數(shù)定義才能進(jìn)行綁定；
• LabelSelector：通過 label 匹配的方式從 PV 列表中選擇合適的 PV 綁定；
• storage：被消費(fèi) PV 的 capacity 必須大于或者等于 PVC 的存儲容量需求才能被綁定。

滿足上述所有需要的 PV 才可以被 PVC 綁定。

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

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

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

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

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

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

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

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

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

兩種卷的比較：

• 動(dòng)態(tài)存儲卷和靜態(tài)存儲卷最終的效果都是：Pod -> PVC -> PV 的使用鏈路，且對象的具體模板定義都是一致的；
• 動(dòng)態(tài)存儲卷和靜態(tài)存儲卷區(qū)別是：動(dòng)態(tài)卷是插件自動(dòng)創(chuàng)建 PV，而靜態(tài)卷是集群管理員手動(dòng)創(chuàng)建 PV。

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

• 動(dòng)態(tài)卷讓 K8s 實(shí)現(xiàn)了 PV 的自動(dòng)化生命周期管理，PV 的創(chuàng)建、刪除都通過 Provisioner 完成；
• 自動(dòng)化創(chuàng)建 PV 對象，減少了配置復(fù)雜度和系統(tǒng)管理員的工作量；
• 動(dòng)態(tài)卷可以實(shí)現(xiàn) PVC 對存儲的需求容量和 Provision 出來的 PV 容量一致，實(shí)現(xiàn)存儲容量規(guī)劃最優(yōu)。

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

當(dāng)用戶聲明一個(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)建的，并通過 StorageClassName 與 PVC 進(jìn)行關(guān)聯(lián)。

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

StorageClasss 模板定義如下：

apiVersion: storage.k8s.io/v1 kind: StorageClass metadata:name: alicloud-disk-topology parameters:type: cloud_ssd provisioner: diskplugin.csi.alibabacloud.com reclaimPolicy: Delete allowVolumeExpansion: true volumeBindingMode: WaitForFirstConsumer

• provisioner：為一個(gè)注冊插件的名字，此插件實(shí)現(xiàn)了創(chuàng)建 PV 的功能；一個(gè) StorageClass 只能定義一個(gè)Provisioner；
• parameters：表示創(chuàng)建數(shù)據(jù)卷的具體參數(shù)；例如這里表示創(chuàng)建一個(gè) SSD 類型的云盤；
• reclaimPolicy：用來指定創(chuàng)建 PV 的 persistentVolumeReclaimPolicy 字段值，支持 Delete/Retain；Delete 表示動(dòng)態(tài)創(chuàng)建的 PV，在銷毀的時(shí)候也會(huì)自動(dòng)銷毀；Retain 表示動(dòng)態(tài)創(chuàng)建的 PV，不會(huì)自動(dòng)銷毀，而是由管理員來處理；
• allowVolumeExpansion：定義由此存儲類創(chuàng)建的 PV 是否運(yùn)行動(dòng)態(tài)擴(kuò)容，默認(rèn)為 false；是否能動(dòng)態(tài)擴(kuò)容是有底層存儲插件來實(shí)現(xiàn)的，這里只是一個(gè)開關(guān)；
• volumeBindingMode：表示動(dòng)態(tài)創(chuàng)建 PV 的時(shí)間，支持 Immediate/WaitForFirstConsumer；分別表示立即創(chuàng)建和延遲創(chuàng)建。

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

• Volume Provisioner 會(huì) watch 到這個(gè) PVC 的存在，若這個(gè) PVC 定義了 StorageClassName，且 StorageClass 對象中定義的 Provisioner 插件是自己，Provisioner 會(huì)觸發(fā)創(chuàng)建 PV 的流程；
• Provisioner 根據(jù) PVC 定義的參數(shù)（Size、VolumeMode、AccessModes）以及 StorageClass 定義的參數(shù)（ReclaimPolicy、Parameters）執(zhí)行 PV 創(chuàng)建；
• Provisioner 會(huì)在存儲介質(zhì)端創(chuàng)建數(shù)據(jù)卷（通過 API 調(diào)用，或者其他方式），完成后會(huì)創(chuàng)建 PV 對象；
• PV 創(chuàng)建完成后，實(shí)現(xiàn)與 PVC 的綁定；以滿足后續(xù)的 Pod 啟動(dòng)流程。

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

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

• 創(chuàng)建了 A 可用區(qū)的數(shù)據(jù)卷，但是 A 可用區(qū)的節(jié)點(diǎn)資源已經(jīng)耗光，導(dǎo)致 Pod 啟動(dòng)無法完成掛載；
• 集群管理員在規(guī)劃 PVC、PV 的時(shí)候不能確定在哪些可用區(qū)創(chuàng)建多個(gè) PV 來備用。

StorageClass 中的 volumeBindingMode 字段正是用來解決此問題，如果將 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ì)講解存儲調(diào)度）；且調(diào)度器會(huì)將調(diào)度結(jié)果 patch 到 PVC 的 metadata 中；
• 當(dāng) Provisioner 發(fā)現(xiàn) PVC 中寫入了調(diào)度信息時(shí)，會(huì)根據(jù)調(diào)度信息獲取創(chuàng)建目標(biāo)數(shù)據(jù)卷的位置信息（zone、Node），并觸發(fā) PV 的創(chuàng)建流程。

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

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

3. 使用示例

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

apiVersion: v1 kind: PersistentVolumeClaim metadata:name: nas-pvc spec:accessModes:- ReadWriteOnceresources:requests:storage: 50Giselector:matchLabels:alicloud-pvname: nas-csi-pv --- apiVersion: v1 kind: PersistentVolume metadata:name: nas-csi-pvlabels:alicloud-pvname: nas-csi-pv spec:capacity:storage: 50GiaccessModes:- ReadWriteOncepersistentVolumeReclaimPolicy: RetainflexVolume:driver: "alicloud/nas"options:server: "***-42ad.cn-shenzhen.extreme.nas.aliyuncs.com"path: "/share/nas" --- apiVersion: apps/v1 kind: Deployment metadata:name: deployment-naslabels:app: nginx spec:selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- name: nginx1image: nginx:1.8- name: nginx2image: nginx:1.7.9volumeMounts:- name: nas-pvcmountPath: "/data"volumes:- name: nas-pvcpersistentVolumeClaim:claimName: nas-pvc

模板解析：

• 此應(yīng)用為 Deployment 方式編排的一個(gè) Nginx 服務(wù)，每個(gè) pod 包含 2 個(gè)容器：nginx1、nginx2；
• 模板中定義了 Volumes 字段，說明期望掛載數(shù)據(jù)卷給應(yīng)用使用，此例中使用了 PVC 這種數(shù)據(jù)卷定義方式；
• 應(yīng)用內(nèi)部：將數(shù)據(jù)卷 nas-pvc 掛載到 nginx2容器的 /data 目錄上；nginx1 容器并沒有掛載；
• PVC（nas-pvc）定義為一個(gè)不小于 50G 容量、讀寫方式為 ReadWriteOnce 的存儲卷需求，且對 PV 有 Label 設(shè)置的需求；
• PV（nas-csi-pv）定義為一個(gè)容量為 50G、讀寫方式為 ReadWriteOnce、回收模式為 Retain、類型為 Flexvolume 抽象類型的存儲卷，且具有 Label 配置；

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

總結(jié)

此篇文章較為詳細(xì)的講述了容器存儲的整體面貌，包括單機(jī)范圍的 Docker 數(shù)據(jù)卷、和集群式的 K8s 數(shù)據(jù)卷；K8s 數(shù)據(jù)卷更多關(guān)注的時(shí)候集群級別的存儲編排能力，同時(shí)也在節(jié)點(diǎn)上實(shí)現(xiàn)了具體的數(shù)據(jù)卷掛載流程。K8s 為了實(shí)現(xiàn)上述復(fù)雜的存儲卷編排能力，其實(shí)現(xiàn)架構(gòu)也較為復(fù)雜，下節(jié)內(nèi)容我們將為您介紹 K8s 的存儲架構(gòu)和實(shí)現(xiàn)流程。

課程推薦

為了更多開發(fā)者能夠享受到 Serverless 帶來的紅利，這一次，我們集結(jié)了 10+ 位阿里巴巴 Serverless 領(lǐng)域技術(shù)專家，打造出最適合開發(fā)者入門的 Serverless 公開課，讓你即學(xué)即用，輕松擁抱云計(jì)算的新范式——Serverless。

點(diǎn)擊即可免費(fèi)觀看課程：https://developer.aliyun.com/learning/roadmap/serverless

“阿里巴巴云原生關(guān)注微服務(wù)、Serverless、容器、Service Mesh 等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢、云原生大規(guī)模的落地實(shí)踐，做最懂云原生開發(fā)者的公眾號。”

總結(jié)

以上是生活随笔為你收集整理的云原生存储详解：容器存储与 K8s 存储卷的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。