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

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

云原生存儲(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. 容器讀寫層

為了提高節(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í)是可以在容器里隨意讀寫的，這是如何實(shí)現(xiàn)的呢？

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

如上圖所示例子，一個(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 組成。

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

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

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

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

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

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

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

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

寫時(shí)復(fù)制(CoW：copy-on-write)，表示只在需要寫時(shí)才去復(fù)制，是針對(duì)已有文件的修改場(chǎng)景。CoW 技術(shù)可以讓所有的容器共享 image 的文件系統(tǒng)，所有數(shù)據(jù)都從 image 中讀取，只有當(dāng)要對(duì)文件進(jìn)行寫操作時(shí)，才從 image 里把要寫的文件復(fù)制到最上面的讀寫層進(jìn)行修改。所以無(wú)論有多少個(gè)容器共享同一個(gè) image，所做的寫操作都是對(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)景，只有在要新寫入一個(gè)文件時(shí)才分配空間，這樣可以提高存儲(chǔ)資源的利用率。比如啟動(dòng)一個(gè)容器，并不會(huì)為這個(gè)容器預(yù)分配一些磁盤空間，而是當(dāng)有新文件寫入時(shí)，才按需分配新空間。

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

存儲(chǔ)驅(qū)動(dòng)是指如何對(duì)容器的各層數(shù)據(jù)進(jìn)行管理，已達(dá)到上述需要實(shí)現(xiàn)共享、可讀寫的效果。即：容器存儲(chǔ)驅(qū)動(dòng)實(shí)現(xiàn)了容器讀寫層數(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)是可寫的。當(dāng)需要修改一個(gè)文件時(shí)，AUFS 創(chuàng)建該文件的一個(gè)副本，使用 CoW 將文件從只讀層復(fù)制到可寫層進(jìn)行修改，結(jié)果也保存在可寫層。在 Docker 中，底下的只讀層就是 image，可寫層就是 Container 運(yùn)行時(shí)。

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

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

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

另一方面：容器本身的存儲(chǔ)數(shù)據(jù)都是臨時(shí)存儲(chǔ)，在容器銷毀的時(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ǔ)組成：只讀層(容器鏡像) + 讀寫層 + 外置存儲(chǔ)(數(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)注的是集群級(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)的可寫層，數(shù)據(jù)卷讀寫是直接對(duì)外置存儲(chǔ)進(jìn)行讀寫，效率更高；
• 對(duì)數(shù)據(jù)卷的更新是對(duì)外置存儲(chǔ)讀寫，不會(huì)影響鏡像和容器讀寫層；
• 數(shù)據(jù)卷可以一直存在，直到?jīng)]有容器使用。

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

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ǔ)類型的接入。

Tmpfs：非持久化的卷類型，存儲(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 類型

• 匿名數(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ī)上沒(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ǔ)類型的需求，docker 提出了通過(guò)存儲(chǔ)插件的方式掛載不同類型的存儲(chǔ)服務(wù)。擴(kuò)展插件統(tǒng)稱為 Volume Driver，可以為每種存儲(chǔ)類型開(kāi)發(fā)一種存儲(chǔ)插件。

• 單個(gè)節(jié)點(diǎn)上可以部署多個(gè)存儲(chǔ)插件；
• 一個(gè)存儲(chǔ)插件負(fù)責(zé)一種存儲(chǔ)類型的掛載服務(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，可以是相同類型或不同類型的存儲(chǔ)；
• Pod 的每個(gè) container 可以引用一個(gè)或多個(gè) volume，不同 container 可以同時(shí)使用相同 volume。

K8S Volume 常用類型：

• 本地存儲(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 等類型，這些存儲(chǔ)卷的特點(diǎn)是數(shù)據(jù)不在集群的某個(gè)節(jié)點(diǎn)上，而是在遠(yuǎn)端的存儲(chǔ)服務(wù)上，使用存儲(chǔ)卷時(shí)需要將存儲(chǔ)服務(wù)掛載到本地使用；
• Secret/ConfigMap：這些存儲(chǔ)卷類型，其數(shù)據(jù)是集群的一些對(duì)象信息，并不屬于某個(gè)節(jié)點(diǎn)，使用時(shí)將對(duì)象數(shù)據(jù)以卷的形式掛載到節(jié)點(diǎn)上供應(yīng)用使用；
• CSI/Flexvolume：這是兩種數(shù)據(jù)卷擴(kuò)容方式，可以理解為抽象的數(shù)據(jù)卷類型。每種擴(kuò)展方式都可再細(xì)化成不同的存儲(chǔ)類型；
• 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 的縮寫，譯為存儲(chǔ)聲明；PVC 是在 K8s 中一種抽象的存儲(chǔ)卷類型，代表了某個(gè)具體類型存儲(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 的縮寫，譯為持久化存儲(chǔ)卷；PV 在 K8s 中代表一個(gè)具體存儲(chǔ)類型的卷，其對(duì)象中定義了具體存儲(chǔ)類型和卷參數(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ǔ)類型，需要定義詳細(xì)的存儲(chǔ)信息，而應(yīng)用層用戶在消費(fèi)存儲(chǔ)服務(wù)的時(shí)候往往不希望對(duì)底層細(xì)節(jié)知道的太多，讓應(yīng)用編排層面來(lái)定義具體的存儲(chǔ)服務(wù)不夠友好。這時(shí)對(duì)存儲(chǔ)服務(wù)再次進(jìn)行抽象，只把用戶關(guān)系的參數(shù)提煉出來(lái)，用 PVC 來(lái)抽象更底層的 PV。所以 PVC、PV 關(guān)注的對(duì)象不一樣，PVC 關(guān)注用戶對(duì)存儲(chǔ)需求，給用戶提供統(tǒng)一的存儲(chǔ)定義方式；而 PV 關(guān)注的是存儲(chǔ)細(xì)節(jié)，可以定義具體存儲(chǔ)類型、存儲(chǔ)掛載使用的詳細(xì)參數(shù)等。

使用時(shí)應(yīng)用層會(huì)聲明一個(gè)對(duì)存儲(chǔ)的需求(PVC)，而 K8s 會(huì)通過(guò)最佳匹配的方式選擇一個(gè)滿足 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 常由專門的存儲(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ǔ)的讀寫模式、資源容量、卷模式等；主要參數(shù)說(shuō)明如下：

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

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

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

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

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

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

4)PV 詳細(xì)定義

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

5)PVC/PV 綁定

PVC 只有綁定了 PV 之后才能被 Pod 使用，而 PVC 綁定 PV 的過(guò)程即是消費(fèi) PV 的過(guò)程，這個(gè)過(guò)程是有一定規(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：通過(guò) label 匹配的方式從 PV 列表中選擇合適的 PV 綁定；
• storage：被消費(fèi) PV 的 capacity 必須大于或者等于 PVC 的存儲(chǔ)容量需求才能被綁定。

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

如果同時(shí)有多個(gè) PV 滿足需求，則需要從 PV 中選擇一個(gè)更合適的進(jìn)行綁定；通常選擇容量最小的，如果容量最小的也有多個(gè)，則隨機(jī)選擇。如果沒(méi)有滿足上述需求的 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ǔ)抽象，一般有專門的集群管理人員定義、維護(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ù)的訪問(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)用戶聲明一個(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ǔ)類，表示為一個(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 類型的云盤；
• reclaimPolicy：用來(lái)指定創(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)銷毀，而是由管理員來(lái)處理；
• allowVolumeExpansion：定義由此存儲(chǔ)類創(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)建。

用戶創(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 的綁定；以滿足后續(xù)的 Pod 啟動(dòng)流程。

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

某種存儲(chǔ)(阿里云云盤)在掛載屬性上有所限制，只能將相同可用區(qū)的數(shù)據(jù)卷和 Node 節(jié)點(diǎn)進(jìn)行掛載，不在同一個(gè)可用區(qū)不可以掛載。這種類型的存儲(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 中寫入了調(diào)度信息時(shí)，會(huì)根據(jù)調(diào)度信息獲取創(chuàng)建目標(biāo)數(shù)據(jù)卷的位置信息(zone、Node)，并觸發(fā) PV 的創(chuàng)建流程。

通過(guò)上述流程可見(jiàn)：延遲綁定會(huì)先讓應(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 容量、讀寫方式為 ReadWriteOnce 的存儲(chǔ)卷需求，且對(duì) PV 有 Label 設(shè)置的需求；
• PV(nas-csi-pv)定義為一個(gè)容量為 50G、讀寫方式為 ReadWriteOnce、回收模式為 Retain、類型為 Flexvolume 抽象類型的存儲(chǔ)卷，且具有 Label 配置；

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

總結(jié)

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

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

總結(jié)

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

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