從一個例子入手PV、PVC

Kubernetes 專案引入了一組叫作 Persistent Volume Claim（PVC）和 Persistent Volume（PV）的 API 物件用於管理儲存卷。

簡單的說PersistentVolume (PV) 是叢集中已由管理員配置的一段網路儲存，是持久化儲存資料卷；Persistent Volume Claim（PVC）描述的，則是 Pod 所希望使用的持久化儲存的屬性，比如，Volume 儲存的大小、可讀寫許可權等等。

上面的這段文字說明可能過於模糊，下面舉個例子看看：

我們定義一個PVC，宣告需要的Volume屬性：

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

yaml檔案中定義了一個1 GiB的PVC，Access Modes表示需要的volume儲存型別，ReadWriteOnce表示只能在一個node節點上進行讀寫操作，其他的Access Modes詳見：https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes。

然後再定義一個PV：

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

這個 PV 物件中會詳細定義儲存的型別是NFS，以及大小是1 GiB。

PVC和PV相當於“介面”和“實現”，所以我們需要將PVC和PV繫結起來才可以使用，而PVC和PV繫結的時候需要滿足：

1. PV 和 PVC 的 spec 欄位要匹配，比如PV 的儲存（storage）大小，就必須滿足 PVC 的要求。
2. PV 和 PVC 的 storageClassName 欄位必須一樣才能進行繫結。storageClassName表示的是StorageClass的name屬性。

做好PVC的宣告之後，並建立好PV，然後就可以使用這個PVC了：

apiVersion: v1
kind: Pod
metadata:
  labels:
    role: web-frontend
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
 

在Pod中只需要宣告PVC的名字，等Pod建立後kubelet 就會把這個 PVC 所對應的 PV，也就是一個 NFS 型別的 Volume，掛載在這個 Pod 容器內的目錄上。

PersistentVolumeController會不斷地檢視當前每一個 PVC，是不是已經處於 Bound（已繫結）狀態。如果不是，那它就會遍歷所有的、可用的 PV，並嘗試將其與這個“單身”的 PVC 進行繫結。所以如果出現沒有PV可以和PVC繫結，那麼Pod 的啟動就會報錯。

這個時候就需要用到StorageClass了，在上面我們說的PV和PVC繫結的過程稱為Static Provisioning，需要手動的建立PV；StorageClass還提供了Dynamic Provisioning機制，可以根據模板建立PV。

StorageClass的Dynamic Provisioning

StorageClass 物件會定義如下兩個部分內容：

1. PV 的屬性。比如，儲存型別、Volume 的大小等等。
2. 建立這種 PV 需要用到的儲存外掛。比如，Ceph 等等。

這樣k8s就能夠根據使用者提交的 PVC，找到一個對應的 StorageClass ，然後呼叫該 StorageClass 宣告的儲存外掛，創建出需要的 PV。

例如宣告如下StorageClass：

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: block-service
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-ssd

這裡定義了名叫 block-service 的 StorageClass，provisioner 欄位的值是：kubernetes.io/gce-pd，這是k8s內建的儲存外掛，type欄位也是跟著provisioner定義的，官方預設支援 Dynamic Provisioning 的內建儲存外掛：https://kubernetes.io/docs/concepts/storage/storage-classes/。

然後就可以在PVC中宣告storageClassName為block-service，當建立好PVC 物件之後，k8s就會呼叫相應的儲存外掛API建立一個PV物件。

如下：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: claim1
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: block-service
  resources:
    requests:
      storage: 30Gi

這種自動建立PV的機制就是Dynamic Provisioning，Kubernetes 就能夠根據使用者提交的 PVC，找到一個對應的 StorageClass ，然後會呼叫StorageClass 宣告的儲存外掛，創建出需要的 PV。

需要注意的是，如果沒有宣告StorageClassName在PVC中，PVC 的 storageClassName 的值就是""，這也意味著它只能夠跟 storageClassName 也是""的 PV 進行繫結。

PV和PVC的生命週期

PV和PVC之間的相互作用遵循這個生命週期:

Provisioning --->Binding --->Using --->Reclaiming

Provisioning

k8s提供了兩種PV生成方式： statically or dynamically

statically：由管理員建立PV，它們攜帶可供叢集使用者使用的真實儲存的詳細資訊。 它們存在於Kubernetes API中，可用於消費。

dynamically：當管理員建立的靜態PV都不匹配使用者的PersistentVolumeClaim時，叢集可能會嘗試為PVC動態配置卷。 此配置基於StorageClasses，PVC必須請求一個StorageClasses，並且管理員必須已建立並配置該類才能進行動態配置。

Binding

由使用者建立好PersistentVolumeClaim 後，PersistentVolumeController會不斷地檢視當前每一個 PVC，是不是已經處於 Bound（已繫結）狀態。如果不是，那它就會遍歷所有的、可用的 PV，並嘗試將其與這個“單身”的 PVC 進行繫結。

Using

Pods宣告並使用PVC作為volume後，叢集會找到該PVC，如果該PVC已經綁定了PV，那麼會將該volume掛載到Pod中。

Reclaiming

當用戶已經不再使用該volume，可以將該PVC刪除，以便讓資源得以回收。相應的在PVC刪除後，PV的回收策略可以是Retained, Recycled, or Deleted，這個策略可以在欄位spec.persistentVolumeReclaimPolicy中設定。

• Retain：這個策略允許手動回收資源，當PVC被刪除後，PV仍然可以存在，管理員可以手動的執行刪除PV，並且和PV繫結的儲存資源也不會被刪除，如果想要刪除相應的儲存資源的資料，需要手動刪除對應儲存資源的資料。
• Delete：這個策略會在PVC被刪除之後，連帶將PV以及PV管理的儲存資源也刪除。
• Recycle：相當於在volume中執行rm -rf /thevolume/*命令，以便讓volume可以重複利用。

刪除流程

一般的情況下，我們遵循這個刪除流程：

1. 刪除使用這個 PV 的 Pod；
2. 從宿主機移除本地磁碟（比如，umount 它）；
3. 刪除 PVC；
4. 刪除 PV。

Local Persistent Volume實戰

Local Persistent Volume適用於類似分散式資料儲存比如 MongoDB、Cassandra等需要在多個不同節點上儲存資料，並且對I/O 較為敏感的應用。但是相比於正常的 PV，一旦這些節點宕機且不能恢復時，Local Persistent Volume 的資料就可能丟失。

在我們的實驗環境中，在宿主機上掛載幾個 RAM Disk（記憶體盤）來模擬本地磁碟。例如：

我們在node1節點上掛載幾個磁碟

$ mkdir /mnt/disks
$ for vol in vol1 vol2 vol3; do
    mkdir /mnt/disks/$vol
    mount -t tmpfs $vol /mnt/disks/$vol
done

然後建立相應的PV：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: example-pv
spec:
  capacity:
    storage: 512Mi
  volumeMode: Filesystem
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Delete
  storageClassName: local-storage
  local:
    path: /mnt/disks/vol1
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - node1

這個 PV 的定義裡：local 欄位指定了它是一個 Local Persistent Volume；而 path 欄位，指定的正是這個 PV 對應的本地磁碟的路徑，即：/mnt/disks/vol1。並且用nodeAffinity指定這個PV必須執行在node1節點上。

執行上面的PV：

$ kubectl create -f local-pv.yaml 
persistentvolume/example-pv created

$ kubectl get pv
NAME         CAPACITY   ACCESS MODES   RECLAIM POLICY  STATUS      CLAIM             STORAGECLASS    REASON    AGE
example-pv   512Mi        RWO            Delete           Available                     local-storage             16s

然後建立一個StorageClass 來描述這個 PV：

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: local-storage
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer

這個 StorageClass叫local-storage，provisioner為no-provisioner表示不需要自動建立PV。

volumeBindingMode=WaitForFirstConsumer表示需要等到Pod執行之後才讓PVC和PV繫結。因為在使用Local Persistent Volume的時候PV和對應的PVC必須要跟隨Pod在同一node下面，否則會排程失敗。

然後我們執行StorageClass：

$ kubectl create -f local-sc.yaml 
storageclass.storage.k8s.io/local-storage created

再建立一個PVC：

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: example-local-claim
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 512Mi
  storageClassName: local-storage

這裡注意宣告storageClassName需要是我們上面建立的StorageClass。

然後建立PVC：

$ kubectl create -f local-pvc.yaml 
persistentvolumeclaim/example-local-claim created

$ kubectl get pvc
NAME                  STATUS    VOLUME    CAPACITY   ACCESS MODES   STORAGECLASS    AGE
example-local-claim   Pending                                       local-storage   7s

這個時候因為還沒建立Pod，所以狀態還是Pending。

建立一個pod：

kind: Pod
apiVersion: v1
metadata:
  name: example-pv-pod
spec:
  volumes:
    - name: example-pv-storage
      persistentVolumeClaim:
       claimName: example-local-claim
  containers:
    - name: example-pv-container
      image: nginx
      ports:
        - containerPort: 80
          name: "http-server"
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: example-pv-storage

然後我們建立pod後再看看PVC繫結狀態：

$ kubectl create -f local-pod.yaml 
pod/example-pv-pod created

$ kubectl get pvc
NAME                  STATUS    VOLUME       CAPACITY   ACCESS MODES   STORAGECLASS    AGE
example-local-claim   Bound     example-pv   512Mi        RWO            local-storage   6h

然後我們試著寫入一個檔案到/usr/share/nginx/html中：

$ kubectl exec -it example-pv-pod -- /bin/sh
# cd /usr/share/nginx/html
# touch test.txt


# 在node1上
$ ls /mnt/disks/vol1
test.txt