目錄貼：Kubernetes學習系列
一、簡介
存儲管理與計算管理是兩個不同的問題。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內部生成的文件。