docker修改镜像的存储位置_云原生存储详解：容器存储与 K8s 存储卷（内含赠书福利）...
作者 | 闞俊寶 ?阿里巴巴技術(shù)專家
參與文末留言互動(dòng)，即有機(jī)會(huì)獲得贈(zèng)書福利！
導(dǎo)讀：云原生存儲(chǔ)詳解系列文章將從云原生存儲(chǔ)服務(wù)的概念、特點(diǎn)、需求、原理、使用及案例等方面，和大家一起探討云原生存儲(chǔ)技術(shù)新的機(jī)遇與挑戰(zhàn)。本文為該系列文章的第二篇，會(huì)對(duì)容器存儲(chǔ)的相關(guān)概念進(jìn)行講述，歡迎大家在留言區(qū)參與討論。
相關(guān)文章推薦：
云原生存儲(chǔ)詳解：云原生應(yīng)用的基石
云原生存儲(chǔ)詳解：容器存儲(chǔ)與 K8s 存儲(chǔ)卷
云原生存儲(chǔ)的兩個(gè)關(guān)鍵領(lǐng)域：
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ì)即來自于運(yùn)行容器時(shí)容器鏡像的組織形式。容器通過復(fù)用容器鏡像的技術(shù)，實(shí)現(xiàn)在相同節(jié)點(diǎn)上多個(gè)容器共享一個(gè)鏡像資源(更細(xì)一點(diǎn)說是共享某一個(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ù)，容器鏡像每一層都是只讀的。而通過實(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ǔ)層說明如下：
該節(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ǔ)說明：
容器 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ù)對(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)行修改。所以無論有多少個(gè)容器共享同一個(gè) image，所做的寫操作都是對(duì)從 image 中復(fù)制后在復(fù)本上進(jìn)行，并不會(huì)修改 image 的源文件，且多個(gè)容器操作同一個(gè)文件，會(huì)在每個(gè)容器的文件系統(tǒng)里生成一個(gè)復(fù)本，每個(gè)容器修改的都是自己的復(fù)本，相互隔離，相互不影響。
2)用時(shí)配置
用時(shí)分配：在鏡像中原本沒有某個(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ǔ)和管理。常見的存儲(chǔ)驅(qū)動(dòng)：
AUFS
OverlayFS
Devicemapper
Btrfs
ZFS
以 AUFS 為例，我們來講述一下存儲(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ì)一起刪除。而通過數(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è)容器使用的目錄，它繞過 UFS，包含以下特性：
數(shù)據(jù)卷可以在容器之間共享和重用；
相比通過存儲(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)用更具有便捷性，但也帶來了安全隱患。
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)更多外部存儲(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ī)上沒有/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：源對(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ù)卷掛載的可見性
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)了將容器外部存儲(chǔ)掛載到容器文件系統(tǒng)的方式。為了擴(kuò)展容器對(duì)外部存儲(chǔ)類型的需求，docker 提出了通過存儲(chǔ)插件的方式掛載不同類型的存儲(chǔ)服務(wù)。擴(kuò)展插件統(tǒng)稱為 Volume Driver，可以為每種存儲(chǔ)類型開發(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?nas1Docker Volume Driver 適用在單機(jī)容器環(huán)境或者 swarm 平臺(tái)進(jìn)行數(shù)據(jù)卷管理，隨著 K8s 的流行其使用場(chǎng)景已經(jīng)越來越少，關(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ú)立，通過編排模板進(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é)抽象出來并實(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)用編排層面來定義具體的存儲(chǔ)服務(wù)不夠友好。這時(shí)對(duì)存儲(chǔ)服務(wù)再次進(jìn)行抽象，只把用戶關(guān)系的參數(shù)提煉出來，用 PVC 來抽象更底層的 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ì)通過最佳匹配的方式選擇一個(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:?PersistentVolumeClaim
metadata:
??name:?disk-ssd-web-0
spec:
??accessModes:
??-?ReadWriteOnce
??resources:
????requests:
??????storage:?20Gi
??storageClassName:?alicloud-disk-available
??volumeMode:?Filesystem
PVC 定義的存儲(chǔ)接口包括：存儲(chǔ)的讀寫模式、資源容量、卷模式等；主要參數(shù)說明如下：
accessModes：存儲(chǔ)卷的訪問模式，支持：ReadWriteOnce、ReadWriteMany、ReadOnlyMany 三種模式。
ReadWriteOnce 表示 pvc 只能同時(shí)被一個(gè) pod 以讀寫方式消費(fèi)；
ReadWriteMany 可以同時(shí)被多個(gè) pod 以讀寫方式消費(fèi)；
ReadOnlyMany 表示可以同時(shí)被多個(gè) pod 以只讀方式消費(fèi)。
注意：這里定義的訪問模式只是編排層面的聲明，具體應(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:?PersistentVolume
metadata:
??labels:
????failure-domain.beta.kubernetes.io/region:?cn-shenzhen
????failure-domain.beta.kubernetes.io/zone:?cn-shenzhen-e
??name:?d-wz9g2j5qbo37r2lamkg4
spec:
??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ǔ)卷的訪問模式，支持：ReadWriteOnce、ReadWriteMany、ReadOnlyMany 三種模式；具體含義同 PVC 字段；
capacity：定義存儲(chǔ)卷容量；
persistentVolumeReclaimPolicy：定義回收策略，即刪除 pvc 的時(shí)候如何處理 PV；支持 Delete、Retain 兩種類型，動(dòng)態(tài)數(shù)據(jù)卷部分會(huì)詳細(xì)說明此參數(shù)；
storageClassName：表示存儲(chǔ)卷的使用的存儲(chǔ)類名字，動(dòng)態(tài)數(shù)據(jù)卷部分會(huì)詳細(xì)說明此參數(shù)；
volumeMode：同 PVC 中的 volumeMode 定義；
Flexvolume：此字段表示具體的存儲(chǔ)類型，這里 Flexvolume 為一種抽象的存儲(chǔ)類型，并在 flexvolume 的子配置項(xiàng)中定義了具體的存儲(chǔ)類型、存儲(chǔ)參數(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 的存儲(chǔ)容量需求才能被綁定。
滿足上述所有需要的 PV 才可以被 PVC 綁定。
如果同時(shí)有多個(gè) PV 滿足需求，則需要從 PV 中選擇一個(gè)更合適的進(jìn)行綁定；通常選擇容量最小的，如果容量最小的也有多個(gè)，則隨機(jī)選擇。
如果沒有滿足上述需求的 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 來消費(fèi)。如果負(fù)載中定義了 PVC 需求，K8s 會(huì)通過相關(guān)規(guī)則實(shí)現(xiàn) PVC 和匹配的 PV 進(jìn)行綁定，這樣就實(shí)現(xiàn)了應(yīng)用對(duì)存儲(chǔ)服務(wù)的訪問能力。
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)建、刪除都通過 Provisioner 完成；
自動(dòng)化創(chuàng)建 PV 對(duì)象，減少了配置復(fù)雜度和系統(tǒng)管理員的工作量；
動(dòng)態(tài)卷可以實(shí)現(xiàn) PVC 對(duì)存儲(chǔ)的需求容量和 Provision 出來的 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)建的，并通過 StorageClassName 與 PVC 進(jìn)行關(guān)聯(lián)。
StorageClass 可譯為存儲(chǔ)類，表示為一個(gè)創(chuàng)建 PV 存儲(chǔ)卷的模板；在 PVC 觸發(fā)自動(dòng)創(chuàng)建PV的過程中，即使用 StorageClass 對(duì)象中的內(nèi)容進(jìn)行創(chuàng)建。其內(nèi)容包括：目標(biāo) Provisioner 名字，創(chuàng)建 PV 的詳細(xì)參數(shù)，回收模式等配置。
StorageClasss 模板定義如下：
apiVersion:?storage.k8s.io/v1kind:?StorageClass
metadata:
??name:?alicloud-disk-topology
parameters:
??type:?cloud_ssd
provisioner:?diskplugin.csi.alibabacloud.com
reclaimPolicy:?Delete
allowVolumeExpansion:?true
volumeBindingMode:?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：用來指定創(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：定義由此存儲(chǔ)類創(chuàng)建的 PV 是否運(yùn)行動(dòng)態(tài)擴(kuò)容，默認(rèn)為 false；是否能動(dòng)態(tài)擴(kuò)容是有底層存儲(chǔ)插件來實(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 對(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ù)卷(通過 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ǔ)卷通常遇到如下問題：
創(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ì)講解存儲(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)建流程。
通過上述流程可見：延遲綁定會(huì)先讓應(yīng)用負(fù)載進(jìn)行調(diào)度(確定有充足的資源供 pod 使用)，然后再觸發(fā)動(dòng)態(tài)卷的創(chuàng)建流程，這樣就避免了數(shù)據(jù)卷所在可用區(qū)沒有資源的問題，也避免了存儲(chǔ)預(yù)規(guī)劃的不準(zhǔn)確性問題。
在多可用區(qū)集群環(huán)境中，更推薦使用延遲綁定的動(dòng)態(tài)卷方案，目前阿里云 ACK 集群已經(jīng)支持上述配置方案。
3. 使用示例
下面給出一個(gè) pod 消費(fèi) PVC、PV 的例子：
apiVersion:?v1kind:?PersistentVolumeClaim
metadata:
??name:?nas-pvc
spec:
??accessModes:
??-?ReadWriteOnce
??resources:
????requests:
??????storage:?50Gi
??selector:
????matchLabels:
??????alicloud-pvname:?nas-csi-pv
---
apiVersion:?v1
kind:?PersistentVolume
metadata:
??name:?nas-csi-pv
??labels:
????alicloud-pvname:?nas-csi-pv
spec:
??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/v1
kind:?Deployment
metadata:
??name:?deployment-nas
??labels:
????app:?nginx
spec:
??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 字段，說明期望掛載數(shù)據(jù)卷給應(yīng)用使用，此例中使用了 PVC 這種數(shù)據(jù)卷定義方式；
應(yīng)用內(nèi)部：將數(shù)據(jù)卷 nas-pvc 掛載到 nginx2容器的 /data 目錄上；nginx1 容器并沒有掛載；
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)流程。
-?贈(zèng)書福利?-
6 月 22 日 12：00 前在留言區(qū)歡迎大家討論交流你對(duì)于容器存儲(chǔ)的疑惑，精選留言點(diǎn)贊第 1 名即可免費(fèi)獲得此書！
總結(jié)
以上是生活随笔為你收集整理的docker修改镜像的存储位置_云原生存储详解：容器存储与 K8s 存储卷（内含赠书福利）...的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 360tray.exe是什么进程 360
- 下一篇： 格式说明_ISO11784/85 FDX