PersistentVolume（簡稱PV）和PersistentVolumeClaim（簡稱PVC）

PersistentVolume（持久卷，簡稱PV）是集群內，由管理員提供的網絡存儲的一部分。就像集群中的節點一 樣，PV也是集群中的一種資源。它也像Volume一樣，是一種volume插件，但是它的生命周期卻是和使用它的Pod相互獨立的。PV這個API對 象，捕獲了諸如NFS、ISCSI、或其他云存儲系統的實現細節。
PersistentVolumeClaim（持久卷聲明，簡稱PVC）是用戶的一種存儲請求。它和Pod類似，Pod消耗Node資源，而PVC消耗PV資源。Pod能夠請求特定的資源（如CPU和內存）。PVC能夠請求指定的大小和訪問的模式（可以被映射為一次讀寫或者多次只讀）。
PVC允許用戶消耗抽象的存儲資源，用戶也經常需要各種屬性（如性能）的PV。集群管理員需要提供各種各樣、不同大小、不同訪問模式的PV，而不用向用戶暴露這些volume如何實現的細節。因為這種需求，就催生出一種StorageClass資源。
StorageClass提供了一種方式，使得管理員能夠描述他提供的存儲的等級。集群管理員可以將不同的等級映射到不同的服務等級、不同的后端策略。
供給
PV是集群中的資源，PVC是對這些資源的請求，同時也是這些資源的“提取證”。PV和PVC的交互遵循以下生命周期：
有兩種PV提供的方式：靜態和動態。
靜態
集群管理員創建多個PV，它們攜帶著真實存儲的詳細信息，這些存儲對于集群用戶是可用的。它們存在于Kubernetes API中，并可用于存儲使用。
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv01
namespace: sit
spec:
capacity:
storage: 100Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Recycle
nfs:
server: 10.42.0.55
path: "/opt/public"
動態
當管理員創建的靜態PV都不匹配用戶的PVC時，集群可能會嘗試專門地供給volume給PVC。這種供給基于StorageClass：PVC必須請求這樣一個等級，而管理員必須已經創建和配置過這樣一個等級，以備發生這種動態供給的情況。請求等級配置為“”的PVC，有效地禁用了它自身的動態供給功能。
Kubernetes 1.4 中加入了一個 新的 API 對象 StorageClass，可以定義多個 StorageClass 對象，并可以分別指定存儲插件、設置參數，用于提供不同的存儲卷。這樣的設計讓集群管理員能夠在同一個集群內，定義和提供不同類型的、不同參數的卷（相同或者不同的存儲系統）。這樣的設計還確保了最終用戶在無需了解太多的情況下，有能力選擇不同的存儲選項。
這種場景比較常見的是使用在高級的私有云分布式存儲或者公有云存儲情況下，大多數是集成第三方的
舉例：創建一個slow，另外一個fast的盤在谷歌云上
kind: StorageClass
apiVersion: storage.k8s.io/v1beta1
metadata:
name: slow
provisioner: kubernetes.io/gce-pd
parameters:
type: pd-standard
kind: StorageClass
apiVersion: storage.k8s.io/v1beta1
metadata:
name: fast
provisioner: kubernetes.io/gce-pd
parameters:
type: pd-ssd
綁定
用戶創建一個PVC（或者之前就已經就為動態供給創建了），指定要求存儲的大小和訪問模式。master中有一個控制回路用于監控新的PVC， 查找匹配的PV（如果有），并把PVC和PV綁定在一起。如果一個PV曾經動態供給到了一個新的PVC，那么這個回路會一直綁定這個PV和PVC。另外， 用戶總是至少能得到它們所要求的存儲，但是volume可能超過它們的請求。一旦綁定了，PVC綁定就是專屬的，無論它們的綁定模式是什么。
如果沒找到匹配的PV，那么PVC會無限期得處于unbound未綁定狀態，一旦PV可用了，PVC就會又變成綁定狀態。比如，如果一個供給了很多50G的PV集群，不會匹配要求100G的PVC。直到100G的PV添加到該集群時，PVC才會被綁定。
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: pvc-test01
namespace:
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 100Gi
使用
Pod使用PVC就像使用volume一樣。集群檢查PVC，查找綁定的PV，并映射PV給Pod。對于支持多種訪問模式的PV，用戶可以指定想用的模式。
一旦用戶擁有了一個PVC，并且PVC被綁定，那么只要用戶還需要，PV就一直屬于這個用戶。用戶調度Pod，通過在Pod的volume塊中包含PVC來訪問PV。
kind: Pod
apiVersion: v1
metadata:
name: task-pv-pod
spec:
volumes:
- name: task-pv-storage
persistentVolumeClaim:
claimName: pvc-test01
containers:
- name: task-pv-container
image: nginx
ports:
- containerPort: 80
name: "http-server"
volumeMounts:
- mountPath: "/usr/share/nginx/html"
name: task-pv-storage

釋放
當用戶使用PV完畢后，他們可以通過API來刪除PVC對象。當PVC被刪除后，對應的PV就被認為是已經是“released”了，但還不能再給另外一個PVC使用。前一個PVC的屬于還存在于該PV中，必須根據策略來處理掉。

回收
PV的回收策略告訴集群，在PV被釋放之后集群應該如何處理該PV。當前，PV可以被Retained（保留）、 Recycled（再利用）或者Deleted（刪除）。保留允許手動地再次聲明資源。對于支持刪除操作的PV卷，刪除操作會從Kubernetes中移 除PV對象，還有對應的外部存儲（如AWS EBS，GCE PD，Azure Disk，或者Cinder volume）。動態供給的卷總是會被刪除。

參考：
https://kubernetes.io/blog/2017/03/dynamic-provisioning-and-storage-classes-kubernetes
https://kubernetes.io/docs/tasks/configure-pod-container/configure-persistent-volume-storage/