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

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

“  

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

”  

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

• volumes通過(guò)這種方式,     Docker管理宿主機(jī)文件系統(tǒng)的一部分，默認(rèn)位于     /var/lib/docker/volumes目錄中，由于在創(chuàng)建時(shí)沒(méi)有創(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ō)明。

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

“  

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

”  

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

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteMany
  nfs:
    server: 10.244.1.4
    path: "/nfs"

“  

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

”  

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

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 10Gi

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

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

apiVersion: v1
kind: Pod
metadata:
  labels:
    role: web
spec:
  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)槭裁茨軌蛑苯釉?code>Yaml中直接定義Volume？因?yàn)?code>Kubernetes已經(jīng)幫助我們實(shí)現(xiàn)了這種Volume類型，如果我們有自己的存儲(chǔ)類型，而Kubernetes中并沒(méi)有實(shí)現(xiàn)，這種是沒(méi)有辦法直接在Yaml編排文件中直接定義Volume的。這個(gè)時(shí)候PV PVC面向?qū)ο蟮脑O(shè)計(jì)就體現(xiàn)出其價(jià)值了。這也是在軟件開發(fā)領(lǐng)域經(jīng)常碰到的問(wèn)題,開源軟件無(wú)法滿足要求,但也沒(méi)有提供出可擴(kuò)展的接口,沒(méi)辦法,只能重新造輪子。

我們?cè)陂_發(fā)過(guò)程中經(jīng)常碰到這樣一個(gè)問(wèn)題，在Pod中聲明一個(gè)PVC之后，發(fā)現(xiàn)Pod不能被調(diào)度成功，原因是因?yàn)?code>PVC沒(méi)有綁定到合適的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.在沒(méi)有介紹這套自動(dòng)創(chuàng)建機(jī)制之前，先看看Static Provisioning，什么是Static Provisioning？剛才人工創(chuàng)建PV PVC的方式就是Static Provisioning。你可以在PV PVC編排文件中聲明StorageClass，如果沒(méi)有聲明，那么默認(rèn)為"".具體交互流程如下所示：

 

首先由集群管理員事先去規(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ì)象，做到按需分配，在沒(méi)有增加用戶使用難度的同時(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ù)

#安裝nfs
yum -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", "list", "watch", "create", "delete"]
   -  apiGroups: [""]
      resources: ["persistentvolumeclaims"]
      verbs: ["get", "list", "watch", "update"]
   -  apiGroups: ["storage.k8s.io"]
      resources: ["storageclasses"]
      verbs: ["get", "list", "watch"]
   -  apiGroups: [""]
      resources: ["events"]
      verbs: ["watch", "create", "update", "patch"]
   -  apiGroups: [""]
      resources: ["services", "endpoints"]
      verbs: ["get","create","list", "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/v1
kind: StorageClass
metadata:
  name: nfs-storage
provisioner: fuseim.pri/ifs
reclaimPolicy: 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/v1
kind: StatefulSet
metadata:
  name: es
spec:
  ........
  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)

 

• 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交互流程

 

1. 用戶創(chuàng)建一個(gè)包含     PVC的     Pod
2. PV Controller會(huì)觀察     ApiServer，如果它發(fā)現(xiàn)一個(gè)     PVC已經(jīng)創(chuàng)建完畢但仍然是未綁定的狀態(tài)，它就會(huì)試圖把一個(gè)     PV和     PVC綁定
3. Provision就是從遠(yuǎn)端上一個(gè)具體的存儲(chǔ)介質(zhì)創(chuàng)建一個(gè)     Volume，并且在集群中創(chuàng)建一個(gè)     PV對(duì)象，然后將此     PV和     PVC進(jìn)行綁定
4. Scheduler進(jìn)行多個(gè)維度考量完成后,把     Pod調(diào)度到一個(gè)合適的     Node
5. Kubelet不斷     watch APIServer是否有     Pod要調(diào)度到當(dāng)前所在節(jié)點(diǎn)
6. Pod調(diào)度到某個(gè)節(jié)點(diǎn)之后，它所定義的     PV還沒(méi)有被掛載（     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è)子目錄中
7. 啟動(dòng)容器,并將已經(jīng)掛載到本地的     Volume映射到容器中