Volume、PV、PVC、StorageClass由來(lái)

先思考一個(gè)問(wèn)題，為什么會(huì)引入Volume這樣一個(gè)概念？“

答案很簡(jiǎn)單，為了實(shí)現(xiàn)數(shù)據(jù)持久化，數(shù)據(jù)的生命周期不隨著容器的消亡而消亡。

”在沒有介紹Kubernetes Volume之前，先來(lái)回顧下Docker Volume，Docker Volume常用使用方式有兩種，

volumes通過(guò)這種方式， Docker管理宿主機(jī)文件系統(tǒng)的一部分，默認(rèn)位于 /var/lib/docker/volumes目錄中，由于在創(chuàng)建時(shí)沒有創(chuàng)建指定數(shù)據(jù)卷， docker自身會(huì)創(chuàng)建默認(rèn)數(shù)據(jù)卷；

bind mounts通過(guò)這種方式，可以把容器內(nèi)文件掛載到宿主機(jī)任意目錄。

既然有了Docker Volume，為啥Kubernetes又搞出了自己的Volume？谷歌的標(biāo)新立異？“

答案是否定的，Kubernetes Volume和Docker Volume概念相似，但是又有不同的地方，Kubernetes Volume與Pod的生命周期相同，但與容器的生命周期不相關(guān)。當(dāng)容器終止或重啟時(shí)，Volume中的數(shù)據(jù)也不會(huì)丟失。當(dāng)Pod被刪除時(shí)，Volume才會(huì)被清理。并且數(shù)據(jù)是否丟失取決于Volume的具體類型，比如emptyDir類型的Volume數(shù)據(jù)會(huì)丟失，而持久化類型的數(shù)據(jù)則不會(huì)丟失。另外Kubernetes提供了將近20種Volume類型。

”現(xiàn)在有了Kubernetes的Volume，我們就可以完全可以在Yaml編排文件中填寫上Volume是字段，如下nfs所示：

。。..volumes： - name： static-nfs nfs： server： 12.18.17.240 path： /nfs/data/static

如果你使用ceph作為存儲(chǔ)插件，你可以在編排文件中這樣定義：

volumes： - name： ceph-vol cephfs： monitors： - 12.18.17.241:6789 - 12.18.17.242:6789 user： admin secretRef： name： ceph-secret readOnly： true

當(dāng)然只要是Kubernetes已經(jīng)實(shí)現(xiàn)的數(shù)據(jù)卷類型，你都可以按照如上方式進(jìn)行直接在Yaml編排文件中定義使用。

看到這里其實(shí)已經(jīng)完成了80%的工作，那么為什么還要設(shè)計(jì)多此一舉的PV呢？這個(gè)問(wèn)題先擱置下，后面會(huì)有說(shuō)明。

在沒有說(shuō)明為什么要設(shè)計(jì)多此一舉的PV PVC之前，先來(lái)看看什么是PV PVC？“

PV是對(duì)持久化存儲(chǔ)數(shù)據(jù)卷的一種描述。

”PV通常是由運(yùn)維人員提前在集群里面創(chuàng)建等待使用的一種數(shù)據(jù)卷。如下所示：

apiVersion： v1kind： PersistentVolumemetadata： name： nfsspec： capacity： storage： 10Gi accessModes： - ReadWriteMany nfs： server： 10.244.1.4 path： “/nfs”“

PVC描述的是持久化存儲(chǔ)的屬性，比如大小、讀寫權(quán)限等。

”PVC通常由開發(fā)人員創(chuàng)建，如下所示：

apiVersion： v1kind： PersistentVolumeClaimmetadata： name： nfsspec： accessModes： - ReadWriteMany resources： requests： storage： 10Gi

而用戶創(chuàng)建的PV PVC必須綁定完成之后才能被利用起來(lái)。而PV PVC綁定起來(lái)的前提是PV中spec中聲明字段大小、權(quán)限等必須滿足PVC的要求。

成功綁定之后，就可以在Pod Yaml編排文件中定義和使用。如下所示：

apiVersion： v1kind： Podmetadata： labels： role： webspec： containers： - name： web image： nginx ports： - name： web containerPort： 80 volumeMounts： - name： nfs mountPath： “/usr/share/nginx/html” volumes： - name： nfs persistentVolumeClaim： claimName： nfs

看到這里，我們還會(huì)認(rèn)為僅僅是PV對(duì)Volume多了一層抽象，并不見得比直接在Yaml中聲明Volume高明多少。仔細(xì)思考下，我們?yōu)槭裁茨軌蛑苯釉赮aml中直接定義Volume？因?yàn)镵ubernetes已經(jīng)幫助我們實(shí)現(xiàn)了這種Volume類型，如果我們有自己的存儲(chǔ)類型，而Kubernetes中并沒有實(shí)現(xiàn)，這種是沒有辦法直接在Yaml編排文件中直接定義Volume的。這個(gè)時(shí)候PV PVC面向?qū)ο蟮脑O(shè)計(jì)就體現(xiàn)出其價(jià)值了。這也是在軟件開發(fā)領(lǐng)域經(jīng)常碰到的問(wèn)題，開源軟件無(wú)法滿足要求，但也沒有提供出可擴(kuò)展的接口，沒辦法，只能重新造輪子。

我們?cè)陂_發(fā)過(guò)程中經(jīng)常碰到這樣一個(gè)問(wèn)題，在Pod中聲明一個(gè)PVC之后，發(fā)現(xiàn)Pod不能被調(diào)度成功，原因是因?yàn)镻VC沒有綁定到合適的PV，這個(gè)時(shí)候要求運(yùn)維人員創(chuàng)建一個(gè)PV，緊接著Pod調(diào)度成功。剛才上在介紹PV PVC，它們的創(chuàng)建過(guò)程都是手動(dòng)，如果集群中需要成千上萬(wàn)的PV，那么運(yùn)維人員豈不累死？在實(shí)際操作中，這種方式根本行不通。所以Kubernetes給我們提供了一套自動(dòng)創(chuàng)建PV的機(jī)制Dynamic Provisioning.在沒有介紹這套自動(dòng)創(chuàng)建機(jī)制之前，先看看Static Provisioning，什么是Static Provisioning？剛才人工創(chuàng)建PV PVC的方式就是Static Provisioning。你可以在PV PVC編排文件中聲明StorageClass，如果沒有聲明，那么默認(rèn)為“”。具體交互流程如下所示：

靜態(tài)分配流程

首先由集群管理員事先去規(guī)劃這個(gè)集群中的用戶會(huì)怎樣使用存儲(chǔ)，它會(huì)先預(yù)分配一些存儲(chǔ)，也就是預(yù)先創(chuàng)建一些 PV；然后用戶在提交自己的存儲(chǔ)需求（PVC）的時(shí)候，Kubernetes內(nèi)部相關(guān)組件會(huì)幫助它把PVC PV 做綁定；最后pod使用存儲(chǔ)的時(shí)候，就可以通過(guò)PVC找到相應(yīng)的PV，它就可以使用了。不足之處也非常清楚，首先繁瑣，然后運(yùn)維人員無(wú)法預(yù)知開發(fā)人員的真實(shí)存儲(chǔ)需求，比如運(yùn)維人員創(chuàng)建了多個(gè)100Gi的PV存儲(chǔ)，但是在實(shí)際開發(fā)過(guò)程中，開發(fā)人員只能使用10Gi，這就造成了資源的浪費(fèi)。當(dāng)然Kubernetes也為我們提供更好的使用方式，即Dynamic Provisioning它是什么呢？

“

Dynamic Provisioning包含了創(chuàng)建某種PV所需要的參數(shù)信息，類似于一個(gè)創(chuàng)建PV的模板。具體交互流程如下所示：

”

Kubernetes集群中的控制器，會(huì)結(jié)合PVC和StorageClass的信息動(dòng)態(tài)生成用戶所需要的PV，將PVC PV進(jìn)行綁定后，pod就可以使用PV了。通過(guò) StorageClass配置生成存儲(chǔ)所需要的存儲(chǔ)模板，再結(jié)合用戶的需求動(dòng)態(tài)創(chuàng)建PV對(duì)象，做到按需分配，在沒有增加用戶使用難度的同時(shí)也解放了集群管理員的運(yùn)維工作。

動(dòng)態(tài)PV使用Dynamic Provisioning上面提到過(guò)，運(yùn)維人員不再預(yù)分配PV，而只是創(chuàng)建一個(gè)模板文件，這個(gè)模板文件正是StorageClass。下面以NFS為例進(jìn)行說(shuō)明，動(dòng)態(tài)PV的整個(gè)使用過(guò)程。

安裝NFS服務(wù)

#安裝nfsyum -y install nfs-utils rpcbind#開機(jī)自啟動(dòng)systemctl enable rpcbind nfs-server#配置nfs 文件echo “/nfs/data *（rw，no_root_squash，sync）” 》/etc/exports

部署置備程序

apiVersion： v1

kind： ServiceAccount

metadata：

name： nfs-provisioner

---

kind： ClusterRole

apiVersion： rbac.authorization.k8s.io/v1

metadata：

name： nfs-provisioner-runner

rules：

- apiGroups： ［“”］

resources： ［“persistentvolumes”］

verbs： ［“get”， “l(fā)ist”， “watch”， “create”， “delete”］

- apiGroups： ［“”］

resources： ［“persistentvolumeclaims”］

verbs： ［“get”， “l(fā)ist”， “watch”， “update”］

- apiGroups： ［“storage.k8s.io”］

resources： ［“storageclasses”］

verbs： ［“get”， “l(fā)ist”， “watch”］

- apiGroups： ［“”］

resources： ［“events”］

verbs： ［“watch”， “create”， “update”， “patch”］

- apiGroups： ［“”］

resources： ［“services”， “endpoints”］

verbs： ［“get”，“create”，“l(fā)ist”， “watch”，“update”］

- apiGroups： ［“extensions”］

resources： ［“podsecuritypolicies”］

resourceNames： ［“nfs-provisioner”］

verbs： ［“use”］

---

kind： ClusterRoleBinding

apiVersion： rbac.authorization.k8s.io/v1

metadata：

name： run-nfs-provisioner

subjects：

- kind： ServiceAccount

name： nfs-provisioner

namespace： logging

roleRef：

kind： ClusterRole

name： nfs-provisioner-runner

apiGroup： rbac.authorization.k8s.io

---

kind： Deployment

apiVersion： apps/v1

metadata：

name： nfs-client-provisioner

spec：

selector：

matchLabels：

app： nfs-client-provisioner

replicas： 1

strategy：

type： Recreate

template：

metadata：

labels：

app： nfs-client-provisioner

spec：

serviceAccount： nfs-provisioner

containers：

- name： nfs-client-provisioner

image： quay.io/external_storage/nfs-client-provisioner:latest

imagePullPolicy： IfNotPresent

volumeMounts：

- name： nfs-client

mountPath： /persistentvolumes

env：

- name： PROVISIONER_NAME

value： fuseim.pri/ifs

- name： NFS_SERVER

value： 12.18.7.20

- name： NFS_PATH

value： /nfs/data

volumes：

- name： nfs-client

nfs：

server： 12.18.7.20

path： /nfs/data

創(chuàng)建StorageClass模板

apiVersion： storage.k8s.io/v1kind： StorageClassmetadata： name： nfs-storageprovisioner： fuseim.pri/ifsreclaimPolicy： Retain

這些參數(shù)是通過(guò)Kubernetes創(chuàng)建存儲(chǔ)的時(shí)候，需要指定的一些細(xì)節(jié)參數(shù)。對(duì)于這些參數(shù)，用戶是不需要關(guān)心的，像這里provisioner指的是使用nfs的置備程序。ReclaimPolicy就是說(shuō)動(dòng)態(tài)創(chuàng)建出來(lái)的PV，當(dāng)使用方使用結(jié)束、Pod 及 PVC被刪除后，這塊PV應(yīng)該怎么處理，我們這個(gè)地方寫的是Retain，意思就是說(shuō)當(dāng)使用方pod PVC被刪除之后，這個(gè)PV會(huì)保留。

提交完成模板文件之后，用戶只需要在 Pod yaml文件定義 PVC，即可自動(dòng)創(chuàng)建 PV和 PVC。

apiVersion： apps/v1kind： StatefulSetmetadata： name： esspec： 。。.。。.。。 template： metadata： labels： app： elasticsearch spec： 。。.。。.。。. initContainers： 。。.。。.。。 containers： - name： elasticsearch image： docker.elastic.co/elasticsearch/elasticsearch:7.6.2 。。.。。.。 volumeClaimTemplates： - metadata： name： data labels： app： elasticsearch spec： accessModes： ［ “ReadWriteOnce” ］ storageClassName： nfs-storage resources： requests： storage： 50Gi`

Capacity：存儲(chǔ)對(duì)象的大??；

AccessModes：也是用戶需要關(guān)心的，就是說(shuō)使用這個(gè)PV的方式。它有三種使用方式：ReadWriteOnce是單node讀寫訪問(wèn)；ReadOnlyMany是多個(gè)node只讀訪問(wèn)，常見的一種數(shù)據(jù)共享方式；ReadWriteMany是多個(gè)node上讀寫訪問(wèn)；

StorageClassName：StorageClassName這個(gè)我們剛才說(shuō)了，動(dòng)態(tài)Provisioning時(shí)必須指定的一個(gè)字段，就是說(shuō)我們要指定到底用哪一個(gè)模板文件來(lái)生成PV。

Kubernetes存儲(chǔ)架構(gòu)

存儲(chǔ)架構(gòu)圖

PV Controller： 負(fù)責(zé) PV PVC的綁定、生命周期管理，并根據(jù)需求進(jìn)行數(shù)據(jù)卷的 Provision Delete操作

AD Controller：負(fù)責(zé)存儲(chǔ)設(shè)備的 Attach Detach操作，將設(shè)備掛載到目標(biāo)節(jié)點(diǎn)

Volume Manager：管理卷的 Mount Unmount操作、卷設(shè)備的格式化以及掛載到一些公用目錄上的操作

Volume Plugins：它主要是對(duì)上面所有掛載功能的實(shí)現(xiàn)。 PV Controller、AD Controller、Volume Manager 主要是進(jìn)行操作的調(diào)用，而具體操作則是由 Volume Plugins實(shí)現(xiàn)的。根據(jù)源碼的位置可將 Volume Plugins分為 In-Tree和 Out-of-Tree兩類： In-Tree表示源碼是放在 Kubernetes內(nèi)部的（常見的 NFS、cephfs等），和 Kubernetes一起發(fā)布、管理與迭代，缺點(diǎn)是迭代速度慢、靈活性差； Out-of-Tree的 Volume Plugins的代碼獨(dú)立于 Kubernetes，它是由存儲(chǔ) 提供商實(shí)現(xiàn)的，目前主要有 Flexvolume CSI兩種實(shí)現(xiàn)機(jī)制，可以根據(jù)存儲(chǔ)類型實(shí)現(xiàn)不同的存儲(chǔ)插件

Scheduler：實(shí)現(xiàn)對(duì) Pod的調(diào)度能力，會(huì)根據(jù)一些存儲(chǔ)相關(guān)的的定義去做存儲(chǔ)相關(guān)的調(diào)度

動(dòng)態(tài)PV交互流程

Kubernetes掛載Volume過(guò)程

用戶創(chuàng)建一個(gè)包含 PVC的 Pod

PV Controller會(huì)觀察 ApiServer，如果它發(fā)現(xiàn)一個(gè) PVC已經(jīng)創(chuàng)建完畢但仍然是未綁定的狀態(tài)，它就會(huì)試圖把一個(gè) PV和 PVC綁定

Provision就是從遠(yuǎn)端上一個(gè)具體的存儲(chǔ)介質(zhì)創(chuàng)建一個(gè) Volume，并且在集群中創(chuàng)建一個(gè) PV對(duì)象，然后將此 PV和 PVC進(jìn)行綁定

Scheduler進(jìn)行多個(gè)維度考量完成后，把 Pod調(diào)度到一個(gè)合適的 Node

Kubelet不斷 watch APIServer是否有 Pod要調(diào)度到當(dāng)前所在節(jié)點(diǎn)

Pod調(diào)度到某個(gè)節(jié)點(diǎn)之后，它所定義的 PV還沒有被掛載（ Attach），此時(shí) AD Controller就會(huì)調(diào)用 VolumePlugin，把遠(yuǎn)端的 Volume掛載到目標(biāo)節(jié)點(diǎn)中的設(shè)備上（ /dev/vdb）；當(dāng) Volum Manager 發(fā)現(xiàn)一個(gè) Pod調(diào)度到自己的節(jié)點(diǎn)上并且 Volume已經(jīng)完成了掛載，它就會(huì)執(zhí)行 mount操作，將本地設(shè)備（也就是剛才得到的 /dev/vdb）掛載到 Pod在節(jié)點(diǎn)上的一個(gè)子目錄中

啟動(dòng)容器，并將已經(jīng)掛載到本地的 Volume映射到容器中

總結(jié)本文主要扯了如下內(nèi)容，首先介紹Kubernetes中Volume、PV、PVC、StorageClass由來(lái)，然后介紹了StorageClass使用，最后簡(jiǎn)單介紹了Kubernetes存儲(chǔ)架構(gòu)以及動(dòng)態(tài)存儲(chǔ)交互流程。
編輯：hfy