一、簡介
儲存管理與計算管理是兩個不同的問題。Persistent Volume子系統，對儲存的供應和使用做了抽象，以API形式提供給管理員和使用者使用。要完成這一任務，我們引入了兩個新的API資源：Persistent Volume（持久卷）和Persistent Volume Claim（持久卷消費者）。
Persistent Volume（PV）是叢集之中的一塊網路儲存。跟Node一樣，也是叢集的資源。PV跟Volume(卷)類似，不過會有獨立於Pod的生命週期。這一API物件包含了儲存的實現細節，例如NFS、iSCSI或者其他的雲提供商的儲存系統。Persistent Volume Claim(PVC)是使用者的一個請求。跟Pod類似，Pod消費Node的資源，PVC消費PV的資源。Pod能夠申請特定的資源（CPU和記憶體）；Claim能夠請求特定的尺寸和訪問模式（例如可以載入一個讀寫，以及多個只讀例項）。
二、PV和PVC的生命週期
PV是叢集的資源。PVC是對這一資源的請求，也是對資源的所有權的檢驗。PV和PVC之間的互動遵循如下的生命週期。
2.1 供應
叢集管理員會建立一系列的PV。這些PV包含了為叢集使用者提供的真實儲存資源，它們可利用KubernetesAPI來消費。
2.2 繫結
使用者建立一個包含了容量和訪問模式的持久卷申請。Master會監聽PVC的產生，並嘗試根據請求內容查詢匹配的PV，並把PV和PVC進行繫結。使用者能夠獲取滿足需要的資源，並且在使用過程中可能超出請求數量。
如果找不到合適的卷，這一申請就會持續處於非繫結狀態，一直到出現合適的PV。例如一個叢集準備了很多的50G大小的持久卷，（雖然總量足夠）也是無法響應100G的申請的，除非把100G的PV加入叢集。
2.3 使用
Pod把申請作為捲來使用。叢集會通過PVC查詢繫結的PV，並Mount給Pod。對於支援多種訪問方式的卷，使用者在使用PVC作為卷的時候，可以指定需要的訪問方式。
一旦使用者擁有了一個已經繫結的PVC，被繫結的PV就歸該使用者所有了。使用者的Pods能夠通過在Pod的卷中包含的PVC來訪問他們佔有的PV。
2.4 釋放
當使用者完成對卷的使用時，就可以利用API刪除PVC物件了，而且他還可以重新申請。刪除PVC後，對應的卷被視為“被釋放”，但是這時還不能給其他的PVC使用。之前的PVC資料還儲存在卷中，要根據策略來進行後續處理。
2.5 回收
PV的回收策略向叢集闡述了在PVC釋放卷的時候，應如何進行後續工作。目前可以採用三種策略：保留，回收或者刪除。保留策略允許重新申請這一資源。在持久卷能夠支援的情況下，刪除策略會同時刪除持久卷以及AWS EBS/GCE PD或者Cinder卷中的儲存內容。如果外掛能夠支援，回收策略會執行基礎的擦除操作（rm -rf /thevolume/*），這一卷就能被重新申請了。
三、持久卷PV
3.1 持久卷的型別
持久卷是以外掛方式實現的，目前支援如下外掛：
- GCEPersistentDisk
- AWSElasticBlockStore
- NFS
- iSCSI
- RBD (Ceph Block Device)
- Glusterfs
- HostPath (單節點測試使用)
- 持久卷
3.2 持久卷定義
每個 PV 包含一個 spec 以及 status ，用於描述該卷的規格和狀態。
apiVersion: v1 kind: PersistentVolume metadata: name: pv0001 spec: capacity: storage: 5Gi accessModes: - ReadWriteMany persistentVolumeReclaimPolicy: Recycle nfs: path: "/data/disk1" server: 192.168.20.47 readOnly: false
3.3 Capacity（容量）
一般來說，PV會指定儲存容量。這裡需要使用PV的capcity屬性。目前儲存大小是唯一一個能夠被申請的指標，今後會加入更多屬性，例如IOPS，吞吐能力等。
3.4 AccessModes（訪問模式）
只要資源提供者支援，持久卷能夠被用任何方式載入到主機上。每種儲存都會有不同的能力，每個PV的訪問模式也會被設定成為該卷所支援的特定模式。例如NFS能夠支援多個讀寫客戶端，但是某個NFS PV可能會在伺服器上以只讀方式使用。每個PV都有自己的一系列的訪問模式，這些訪問模式取決於PV的能力。訪問模式的可選範圍如下：
- ReadWriteOnce：該卷能夠以讀寫模式被載入到一個節點上。
- ReadOnlyMany：該卷能夠以只讀模式載入到多個節點上。
- ReadWriteMany：該卷能夠以讀寫模式被多個節點同時載入。
在CLI下，訪問模式縮寫為：
- RWO：ReadWriteOnce
- ROX：ReadOnlyMany
- RWX：ReadWriteMany
另外，一個卷不論支援多少種訪問模式，同時只能以一種訪問模式載入。例如一個GCE Persistent Disk既能支援ReadWriteOnce，也能支援ReadOnlyMany。
3.5 RecyclingPolicy（回收策略）
當前的回收策略可選值包括：
- Retain，人工重新申請
- Recycle，基礎擦除（“rm-rf/thevolume/*”）
- Delete，相關的儲存資產例如AWS EBS，GCE PD或者OpenStack Cinder卷一併刪除。
目前，只有NFS和HostPath支援Recycle策略，AWS EBS、GCE PD以及Cinder卷支援Delete策略。
3.6 階段（Phase）
一個卷會處於如下階段之一：
- Available：可用資源，尚未被繫結到PVC上
- Bound：該卷已經被繫結
- Released：PVC已經被刪除，但該資源尚未被叢集回收
- Failed：該卷的自動回收過程失敗。
四、PersistentVolumeClaims（持久卷消費者）
每個 PVC 包含一個 spec 以及 status，用以表達其規格和狀態。
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: nfs-pvc spec: accessModes: - ReadWriteMany resources: requests: storage: 1Gi
4.1 訪問模式
PVC使用跟PV一致的訪問模式。
4.2 資源
PVC跟Pod一樣可以請求特定數量的資源。在這裡的請求內容就是儲存（storage）。ResourceModel文中提到的內容對PV和PVC同樣適用。
4.3 使用PVC卷
Pod能夠藉助PVC來訪問儲存。PVC必須跟Pod處於同一個名稱空間。叢集找到Pod名稱空間中的PVC，然後利用PVC獲取到背後的PV。這個卷就會被載入到主機上，讓Pod可以使用。
[root@k8s-master pv]# cat test-pvc-pod.yaml apiVersion: v1 kind: Pod metadata: name: test-nfs-pvc labels: name: test-nfs-pvc spec: containers: - name: test-nfs-pvc image: registry:5000/back_demon:1.0 ports: - name: backdemon containerPort: 80 command: - /run.sh volumeMounts: - name: nfs-vol mountPath: /home/laizy/test/nfs-pvc volumes: - name: nfs-vol persistentVolumeClaim: claimName: nfs-pvc [root@k8s-master pv]# kubectl exec -ti test-nfs-pvc /bin/bash [root@test-nfs-pvc /]# cd /home/laizy/test/nfs-pvc/ [root@test-nfs-pvc nfs-pvc]# ls 1.out [root@test-nfs-pvc nfs-pvc]# touch 2.out [root@test-nfs-pvc nfs-pvc]# ls 1.out 2.out
在對應的遠端NFS主機上看，可以看到剛剛在Pod內部生成的檔案。