PV/PVC是什么?
PV(Persistent Volume):描述的是持久化的Volume實體概念,生命周期與Pod創建和銷毀事件無關。要么運行事先準備好,要么通過動態創建。
PVC(PersistentVolumeClaim):PVC是對PV的請求,申明Pod所希望使用的持久化存儲的屬性,例如容量,讀寫權限。
Kubernete Volumes能夠幫忙應用持久化數據,PV/PVC是Kubernetes Volumes存儲類型的一種,其它類型還有:
本地存儲:emptyDir / hostPath
網絡存儲:
in-tree: aws ElasticBlockStore / gcePersistentDisk / nfs
out-of-tree:csi等網絡存儲插件
Project Volume:secret / configmap / downwardAPI / serviceAccountToken
PV/PVC的意義
- 使用不同的控制器來管理計算與存儲資源,解耦POD與Volume的生命周期,實現計算與存儲分離。
- PVC只需要關注應用需要知道的配置,如存儲大小、訪問模式,讀寫模式等,而不需要知道存儲的細節,實現開發與運維職責分離。開發只需要提需求,知道自己需要的存儲容量,模式就夠了,他并不關心存儲是由什么設備提供的,資源池的夠不夠,而運維人員則相反,他更關心的底層的存儲狀態。
PV創建的兩種方式:靜態與動態
靜態創建方式,下圖為靜態創建的示意圖。
靜態創建方式
- 研發用戶需要創建存儲資源,于是創建了PVC(持久化存儲卷請求),申明需要的存儲資源大小以及訪問模式
- 集群管理人員(運維人員)根據需求配置手動創建對應的PV(持久化存儲卷)
- OpenShift/K8S會根據配置將PV/PVC進行綁定,讓PVC與真實的存儲資源關聯。
這種方式有幾個問題:
- 需要手動創建PV,增加了運維管理的復雜度。
- 如果有大量配置一樣的PVC需求時,PVC與設定的PV需要單獨的設置進行綁定。
動態創建方式,下圖為動態創建的示意圖。
動態創建方式
- 集群管理人員(運維人員)提前部署好存儲的provisioner,并創建好對應storageclass
- 研發用戶需要創建存儲資源,于是創建了PVC(持久化存儲卷請求),申明需要的存儲的provisioner以及存儲大小
- provisioner監聽到PVC資源的創建,自動創建PV,并與PVC進行綁定,讓PVC與真實的存儲資源關聯。
一旦準備好動態創建存儲環境,存儲資源便以服務的方式提供給研發人員,實現存儲資源自服務。
如何將PV與PVC綁定
在上一部分介紹了靜態創建存儲資源與動態創建存儲資源的過程與特點,很明顯動態創建存儲資源使用更方便,但是在生產中,受到環境的限制,靜態創建存儲資源的方式仍然很常見。這時,如何準確地綁定PVC與對應的PV就是需要注意的問題了。下面列出了解決這個問題的三種方法。
第一種,在PV中添加label,在PVC中添加matchLabels進行關聯
創建PV
apiVersion: v1
kind: PersistentVolume
metadata:
name: nfs-pv1
labels:
pv: nfs-pv1
spec:
capacity:
storage: 1Gi
accessModes:
- ReadWriteMany
nfs:
server: 10.2.1.2
path: "/exports/pv1"
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc1
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 1Gi
selector:
matchLabels:
pv: "nfs-pv1"
matchExpressions:
- {key: environment, operator: In, values: [dev]}
# 本地盤PV
kind: PersistentVolume
apiVersion: v1
metadata:
name: test2-pv
namespace: kubeflow
labels:
pv: test2
spec:
capacity:
storage: 100Mi
accessModes:
- ReadWriteOnce
hostPath:
path: "/data/test2"
第二種,PV配置中指定關聯的PVC
apiVersion: v1
kind: PersistentVolume
metadata:
name: nfs-pv1
labels:
pv: nfs-pv1
spec:
capacity:
storage: 1Gi
claimRef:
apiVersion: v1
kind: PersistentVolumeClaim
name: openldap-volume-1
namespace: openldap
accessModes:
- ReadWriteMany
nfs:
server: 10.2.1.2
path: "/exports/pv1"
第三種,PVC中設置volumeName
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc1
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 1Gi
volumeName: nfs-pv1