Volume、PV、PVC、StorageClass由來

先思考一個問題，為什么會引入Volume這樣一個概念？

“  

答案很簡單，為了實現數據持久化，數據的生命周期不隨著容器的消亡而消亡。

”  

在沒有介紹Kubernetes Volume之前，先來回顧下Docker Volume，Docker Volume常用使用方式有兩種，

• volumes通過這種方式,     Docker管理宿主機文件系統的一部分，默認位于     /var/lib/docker/volumes目錄中，由于在創建時沒有創建指定數據卷，     docker自身會創建默認數據卷；
• bind mounts通過這種方式,可以把容器內文件掛載到宿主機任意目錄。

既然有了Docker Volume，為啥Kubernetes又搞出了自己的Volume？谷歌的標新立異？

“  

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

”  

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

....
volumes:
    - name: static-nfs
      nfs:
          server: 12.18.17.240
          path: /nfs/data/static

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

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

當然只要是Kubernetes已經實現的數據卷類型，你都可以按照如上方式進行直接在Yaml編排文件中定義使用。

看到這里其實已經完成了80%的工作，那么為什么還要設計多此一舉的PV呢？這個問題先擱置下，后面會有說明。

在沒有說明為什么要設計多此一舉的PV PVC之前，先來看看什么是PV PVC？

“  

PV是對持久化存儲數據卷的一種描述。

”  

PV通常是由運維人員提前在集群里面創建等待使用的一種數據卷。如下所示：

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

“  

PVC描述的是持久化存儲的屬性，比如大小、讀寫權限等。

”  

PVC通常由開發人員創建，如下所示：

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

而用戶創建的PV PVC必須綁定完成之后才能被利用起來。而PV PVC綁定起來的前提是PV中spec中聲明字段大小、權限等必須滿足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

看到這里，我們還會認為僅僅是PV對Volume多了一層抽象，并不見得比直接在Yaml中聲明Volume高明多少。仔細思考下，我們為什么能夠直接在Yaml中直接定義Volume？因為Kubernetes已經幫助我們實現了這種Volume類型，如果我們有自己的存儲類型，而Kubernetes中并沒有實現，這種是沒有辦法直接在Yaml編排文件中直接定義Volume的。這個時候PV PVC面向對象的設計就體現出其價值了。這也是在軟件開發領域經常碰到的問題,開源軟件無法滿足要求,但也沒有提供出可擴展的接口,沒辦法,只能重新造輪子。

我們在開發過程中經常碰到這樣一個問題，在Pod中聲明一個PVC之后，發現Pod不能被調度成功，原因是因為PVC沒有綁定到合適的PV，這個時候要求運維人員創建一個PV，緊接著Pod調度成功。剛才上在介紹PV PVC，它們的創建過程都是手動，如果集群中需要成千上萬的PV，那么運維人員豈不累死？在實際操作中，這種方式根本行不通。所以Kubernetes給我們提供了一套自動創建PV的機制Dynamic Provisioning.在沒有介紹這套自動創建機制之前，先看看Static Provisioning，什么是Static Provisioning？剛才人工創建PV PVC的方式就是Static Provisioning。你可以在PV PVC編排文件中聲明StorageClass，如果沒有聲明，那么默認為"".具體交互流程如下所示：

 

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

“  

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

”  

Kubernetes集群中的控制器，會結合PVC和StorageClass的信息動態生成用戶所需要的PV，將PVC PV進行綁定后，pod就可以使用PV了。通過 StorageClass配置生成存儲所需要的存儲模板，再結合用戶的需求動態創建PV對象，做到按需分配，在沒有增加用戶使用難度的同時也解放了集群管理員的運維工作。

動態PV使用

Dynamic Provisioning上面提到過，運維人員不再預分配PV，而只是創建一個模板文件，這個模板文件正是StorageClass。下面以NFS為例進行說明，動態PV的整個使用過程。

• 安裝NFS服務

#安裝nfs
yum -y install nfs-utils rpcbind
#開機自啟動
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

• 創建StorageClass模板

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: nfs-storage
provisioner: fuseim.pri/ifs
reclaimPolicy: Retain

這些參數是通過Kubernetes創建存儲的時候，需要指定的一些細節參數。對于這些參數，用戶是不需要關心的，像這里provisioner指的是使用nfs的置備程序。ReclaimPolicy就是說動態創建出來的PV,當使用方使用結束、Pod 及 PVC被刪除后，這塊PV應該怎么處理，我們這個地方寫的是Retain，意思就是說當使用方pod PVC被刪除之后，這個PV會保留。

• 提交完成模板文件之后,用戶只需要在     Pod yaml文件定義     PVC,即可自動創建     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：存儲對象的大小；

AccessModes：也是用戶需要關心的，就是說使用這個PV的方式。它有三種使用方式:ReadWriteOnce是單node讀寫訪問；ReadOnlyMany是多個node只讀訪問，常見的一種數據共享方式；ReadWriteMany是多個node上讀寫訪問；

StorageClassName：StorageClassName這個我們剛才說了，動態Provisioning時必須指定的一個字段，就是說我們要指定到底用哪一個模板文件來生成PV。

Kubernetes存儲架構

 

• PV Controller: 負責     PV PVC的綁定、生命周期管理，并根據需求進行數據卷的     Provision Delete操作
• AD Controller：負責存儲設備的     Attach Detach操作，將設備掛載到目標節點
• Volume Manager：管理卷的     Mount Unmount操作、卷設備的格式化以及掛載到一些公用目錄上的操作
• Volume Plugins：它主要是對上面所有掛載功能的實現。     PV Controller、AD Controller、Volume Manager 主要是進行操作的調用，而具體操作則是由     Volume Plugins實現的。根據源碼的位置可將     Volume Plugins分為     In-Tree和     Out-of-Tree兩類：     In-Tree表示源碼是放在     Kubernetes內部的(常見的     NFS、cephfs等)，和     Kubernetes一起發布、管理與迭代，缺點是迭代速度慢、靈活性差；     Out-of-Tree的     Volume Plugins的代碼獨立于     Kubernetes，它是由存儲     提供商實現的，目前主要有     Flexvolume CSI兩種實現機制，可以根據存儲類型實現不同的存儲插件
• Scheduler：實現對     Pod的調度能力，會根據一些存儲相關的的定義去做存儲相關的調度

動態PV交互流程

 

1. 用戶創建一個包含     PVC的     Pod
2. PV Controller會觀察     ApiServer，如果它發現一個     PVC已經創建完畢但仍然是未綁定的狀態，它就會試圖把一個     PV和     PVC綁定
3. Provision就是從遠端上一個具體的存儲介質創建一個     Volume，并且在集群中創建一個     PV對象，然后將此     PV和     PVC進行綁定
4. Scheduler進行多個維度考量完成后,把     Pod調度到一個合適的     Node
5. Kubelet不斷     watch APIServer是否有     Pod要調度到當前所在節點
6. Pod調度到某個節點之后，它所定義的     PV還沒有被掛載（     Attach），此時     AD Controller就會調用     VolumePlugin，把遠端的     Volume掛載到目標節點中的設備上（     /dev/vdb）；當     Volum Manager 發現一個     Pod調度到自己的節點上并且     Volume已經完成了掛載，它就會執行     mount操作，將本地設備（也就是剛才得到的     /dev/vdb）掛載到     Pod在節點上的一個子目錄中
7. 啟動容器,并將已經掛載到本地的     Volume映射到容器中