一、什麼是PV和PVC？
PV的全稱是Persistent Volume，翻譯過來為持久化儲存卷，是對底層的共享儲存的一種抽象，PV由管理員進行建立和配置，主要含儲存能力、訪問模式、儲存型別、回收策略、後端儲存型別等主要資訊，它和具體的底層的共享儲存技術的實現方式有關，比如NFS、Hostpath、RBD等。
PVC的全稱是: PersistenVolumeClaim (持久化卷宣告)，PVC是使用者儲存的一種宣告，PVC和Pod類似，Pod是消耗節點node資源，PVC消耗的是PV資源，Pod可以請求CPU的記憶體，而PVC可以請求特定的儲存空間和訪問模式。
二、PV和PVC的使用場景
配圖來自K8S權威指南第四版
儲存工程師把分散式儲存系統上的總空間劃分成一個一個小的儲存塊，K8S的叢集管理員將儲存塊和PV進行一一對應，使用者通過PVC對對儲存進行申請，比如可以指定具體容量的大小，訪問模式或者儲存型別，這樣的好處是使用者不需要關心底層的儲存實現細節，只需要直接申請使用PVC即可，若申請的PVC所對應的PV不能滿足使用者的要求，不會生效，直到有合適的PV生成，PVC會自動與PV完成繫結，儲存工程師、K8S管理員，使用者之間業務解耦，靈活性更強。
三、建立PV
PV支援多種不同型別的儲存，如：NFS、hostpath、RBD、ICCSI，本文以hostpath為例介紹如何建立PV
第一步：現在宿主機data目錄下data/pod/volume1，volume1將作為PV對應的hostpath本地儲存的目錄
第二步：通過yaml檔案建立PV
1 [root@k8s-master zhanglei]# cat pv-hostpath.yaml
2 kind: PersistentVolume #指定為PV型別
3 apiVersion: v1
4 metadata:
5 name: pv-statefulset #指定PV的名稱
6 labels: #指定PV的標籤
7 release: stable
8 spec:
9 capacity:
10 storage: 0.1Gi #指定PV的容量
11 accessModes:
12 - ReadWriteOnce #指定PV的訪問模式，簡寫為RWO，只支援掛在1個Pod的讀和寫
13 persistentVolumeReclaimPolicy: Recycle #指定PV的回收策略，Recycle表示支援回收，回收完成後支援再次利用
14 hostPath: #指定PV的儲存型別，本文是以hostpath為例
15 path: /data/pod/volume1 #指定PV對應後端儲存hostpath的目錄
說明：
accessModes支援多種訪問模式
1）ReadWriteOnce（RWO）：讀寫許可權，但是隻支援掛載在1個Pod
2）ReadOnlyMany（ROX）：只讀許可權，支援掛載在多個Pod
3）ReadWriteMany（RW）：讀寫許可權，支援掛載在多個Pod上
persistentVolumeReclaimPolicy的策略，指的是如果PVC被釋放掉後，PV的處理，這裡所說的釋放，指的是使用者刪除PVC後，與PVC對應的PV會被釋放掉，PVC個PV是一一對應的關係
1）Retain，PV的資料不會清理，會保留volume，如果需要清理，需要手動進行
2）Recycle，會將資料進行清理，即 rm -rf /thevolume/*（只有 NFS 和 HostPath 支援），清理完成後，PV會呈available狀態，支援再次的bound
3）Delete，刪除儲存資源，會刪除PV及後端的儲存資源，比如刪除 AWS EBS 卷（只有 AWS EBS, GCE PD, Azure Disk 和 Cinder 支援）
四、建立PVC
[root@k8s-master zhanglei]# cat pvc-hostpath.yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: mppvc-01 # 指定PVC的名稱 namespace: default spec: accessModes: ["ReadWriteOnce"] # 指定PVC的訪問模式 resources: requests: storage: 0.05Gi # PVC申請的容量
說明：
1）PVC宣告瞭accessModes訪問型別為ReadWriteOnce，建立後，系統會自動去找能夠支援ReadWriteOnce訪問型別的PV，若無符合條件的PV，則不會進行繫結，
2）PVC宣告瞭storage的大小為0.05Gi，建立後，系統會自動去找能夠支援此容量的PV，通常PV的容量至少要大於或者等於0.05Gi才會去進行繫結
從這裡來看，對於使用者來說，即只需要宣告訪問型別、容量、另外還可通過StorageClass宣告具體的PV型別即可完成對持久化儲存卷的申請，而不需要去維護和關注後端儲存
五、查詢PV和PVC的
經過前面的步驟我們建立了PV和PVC，現在來看下兩者是否已經完成了繫結，在PV的建立已經指定了其名稱為pv-statefulset，PVC的名稱為mppvc-01
[root@k8s-master zhanglei]# kubectl get pv |grep pv-statefulset pv-statefulset 107374182400m RWO Recycle Bound default/mppvc-01
[root@k8s-master zhanglei]# kubectl get pvc |grep mppvc-01 mppvc-01 Bound pv-statefulset 107374182400m RWO 13d
可以看到pv-statefulset這個PV已經和mppvc-01的PVC進行了繫結（Bound），RWO和Recycle也是之前PV和PVC宣告的狀態，說明繫結成功
[root@k8s-master zhanglei]# kubectl describe pv pv-statefulset Name: pv-statefulset Labels: release=stable Annotations: pv.kubernetes.io/bound-by-controller: yes Finalizers: [kubernetes.io/pv-protection] StorageClass: Status: Bound Claim: default/mppvc-01 Reclaim Policy: Recycle Access Modes: RWO VolumeMode: Filesystem Capacity: 107374182400m Node Affinity: <none> Message: Source: Type: HostPath (bare host directory volume) Path: /data/pod/volume1 HostPathType: Events: <none>
[root@k8s-master zhanglei]# kubectl describe pvc mppvc-01 Name: mppvc-01 Namespace: default StorageClass: Status: Bound Volume: pv-statefulset Labels: <none> Annotations: pv.kubernetes.io/bind-completed: yes pv.kubernetes.io/bound-by-controller: yes Finalizers: [kubernetes.io/pvc-protection] Capacity: 107374182400m Access Modes: RWO VolumeMode: Filesystem Mounted By: <none> Events: <none>
再來看下PV的詳細（describe）資訊，可以看到type是hostpath型別，顯示了資料卷在宿主機的/data/pod/volume1的目錄。
六、總結
建立PV個PVC分為二步：
第一步：建立PV，支援自定義不同的儲存大小和訪問模式（RWX，RWO）、存放路徑、後端服務server（如hostpath、或NAS盤的資料盤的掛載點）
第二步：建立PVC，繫結到PV。建立PVC的時候可以指定PVC的request storage，即申請的儲存的容量，會根據申請的storage和訪問模式自動匹配符合要求的PV
建立完PV和PVC主要是為了使用它來達到實現持久化儲存的目的，如何進行使用請看本作者後續與statufulset有關的文章，謝謝閱讀~