k8s高階儲存(PV、PVC)
阿新 • • 發佈：2022-12-04
高階儲存
前面已經學習了使用NFS提供儲存，此時就要求使用者會搭建NFS系統，並且會在yaml配置nfs。由於kubernetes支援的儲存系統有很多，要求客戶全都掌握，顯然不現實。
為了能夠遮蔽底層儲存實現的細節，方便使用者使用， kubernetes引入PV和PVC兩種資源物件。
- PV（Persistent Volume）是持久化卷的意思，是對底層的共享儲存的一種抽象。一般情況下PV由kubernetes管理員進行建立和配置，它與底層具體的共享儲存技術有關，並通過外掛完成與共享儲存的對接。 - PVC（Persistent Volume Claim）是持久卷宣告的意思，是使用者對於儲存需求的一種宣告。換句話說，PVC其實就是使用者向kubernetes系統發出的一種資源需求申請。
使用了PV和PVC之後，工作可以得到進一步的細分：
- 儲存：儲存工程師維護
- PV： kubernetes管理員維護
- PVC：kubernetes使用者維護
PV
資源清單檔案
PV是儲存資源的抽象，下面是資源清單檔案:
apiVersion: v1 kind: PersistentVolume metadata: name: pv2 #注：這裡沒有寫名稱空間NS，因為PV是叢集級別的資源，跨NS使用 spec: nfs: # 儲存型別（nfs、cifs、glusterfs），與底層真正儲存對應 capacity: # 儲存能力，目前只支援儲存空間的設定 storage: 2Gi accessModes: # 訪問模式 storageClassName: # 儲存類別 persistentVolumeReclaimPolicy: # 回收策略
PV 的關鍵配置引數說明：
- 儲存型別
底層實際儲存的型別，kubernetes支援多種儲存型別，每種儲存型別的配置都有所差異
- 儲存能力（capacity）
目前只支援儲存空間的設定( storage=1Gi )，不過未來可能會加入IOPS、吞吐量等指標的配置
- 訪問模式（accessModes）
用於描述使用者應用對儲存資源的訪問許可權，訪問許可權包括下面幾種方式：
- ReadWriteOnce（RWO）：讀寫許可權，但是隻能被單個節點掛載 - ReadOnlyMany（ROX）： 只讀許可權，可以被多個節點掛載 - ReadWriteMany（RWX）：讀寫許可權，可以被多個節點掛載
`需要注意的是，底層不同的儲存型別可能支援的訪問模式不同`
- 回收策略（persistentVolumeReclaimPolicy）
當PV不再被使用了之後，對其的處理方式。目前支援三種策略：
- Retain （保留） 保留資料，需要管理員手工清理資料 - Recycle（回收） 清除 PV 中的資料，效果相當於執行 rm -rf /thevolume/* - Delete （刪除） 與 PV 相連的後端儲存完成 volume 的刪除操作，當然這常見於雲服務商的儲存服務
`需要注意的是，底層不同的儲存型別可能支援的回收策略不同`
- 儲存類別
PV可以通過storageClassName引數指定一個儲存類別
- 具有特定類別的PV只能與請求了該類別的PVC進行繫結
- 未設定類別的PV則只能與不請求任何類別的PVC進行繫結
- 狀態（status）
一個 PV 的生命週期中，可能會處於4中不同的階段：
- Available（可用）： 表示可用狀態，還未被任何 PVC 繫結 - Bound（已繫結）： 表示 PV 已經被 PVC 繫結 - Released（已釋放）： 表示 PVC 被刪除，但是資源還未被叢集重新宣告 - Failed（失敗）： 表示該 PV 的自動回收失敗
案例
使用NFS作為儲存，來演示PV的使用，建立3個PV，對應NFS中的3個暴露的路徑。
1) 準備NFS環境
# 建立目錄 [root@master ~]# mkdir -p /root/data/{pv1,pv2,pv3} # 暴露服務 [root@master ~]# vim /etc/exports [root@master ~]# cat /etc/exports /root/data/pv1 192.168.1.0/24(rw,no_root_squash) /root/data/pv2 192.168.1.0/24(rw,no_root_squash) /root/data/pv3 192.168.1.0/24(rw,no_root_squash) # 重啟服務 [root@master ~]# systemctl restart nfs
2) 建立pv
apiVersion: v1 kind: PersistentVolume metadata: name: pv1 spec: capacity: storage: 1Gi accessModes: - ReadWriteMany persistentVolumeReclaimPolicy: Retain nfs: path: /root/data/pv1 server: 192.168.1.50 --- apiVersion: v1 kind: PersistentVolume metadata: name: pv2 spec: capacity: storage: 2Gi accessModes: - ReadWriteMany persistentVolumeReclaimPolicy: Retain nfs: path: /root/data/pv2 server: 192.168.1.50 --- apiVersion: v1 kind: PersistentVolume metadata: name: pv3 spec: capacity: storage: 3Gi accessModes: - ReadWriteMany persistentVolumeReclaimPolicy: Retain nfs: path: /root/data/pv3 server: 192.168.1.50
建立並檢視
# 建立 pv [root@master ~]# kubectl create -f pv.yaml # 檢視pv [root@master ~]# kubectl get pv -o wide
PVC
PVC是資源的申請，用來宣告對儲存空間、訪問模式、儲存類別需求資訊。下面是資源清單檔案:
資源清單檔案
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc
namespace: dev #有名稱空間NS
spec:
accessModes: # 訪問模式
selector: # 採用標籤對PV選擇
storageClassName: # 儲存類別
resources: # 請求空間
requests:
storage: 5Gi
PVC 的關鍵配置引數說明：
- 訪問模式（accessModes） 用於描述使用者應用對儲存資源的訪問許可權 - 選擇條件（selector） 通過Label Selector的設定，可使PVC對於系統中己存在的PV進行篩選 - 儲存類別（storageClassName） PVC在定義時可以設定需要的後端儲存的類別，只有設定了該class的pv才能被系統選出 - 資源請求（Resources ） 描述對儲存資源的請求
案例
1) 建立pvc.yaml，申請pv
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: pvc1 namespace: dev spec: accessModes: - ReadWriteMany #訪問模式要對應 resources: requests: storage: 1Gi #若申請超過PV的限制，如申請5Gi，則會匹配不上，狀態會變成Pending --- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: pvc2 namespace: dev spec: accessModes: - ReadWriteMany resources: requests: storage: 1Gi --- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: pvc3 namespace: dev spec: accessModes: - ReadWriteMany resources: requests: storage: 1Gi
建立並檢視
# 建立pvc [root@master ~]# kubectl create -f pvc.yaml # 檢視pvc [root@master ~]# kubectl get pvc -n dev -o wide # 檢視pv [root@master ~]# kubectl get pv -o wide
2) 建立pods.yaml, 使用pv
apiVersion: v1 kind: Pod metadata: name: pod1 namespace: dev spec: containers: - name: busybox image: busybox:1.30 command: ["/bin/sh","-c","while true;do echo pod1 >> /root/out.txt; sleep 10; done;"] volumeMounts: - name: volume mountPath: /root/ volumes: - name: volume persistentVolumeClaim: claimName: pvc1 readOnly: false #可讀可寫 --- apiVersion: v1 kind: Pod metadata: name: pod2 namespace: dev spec: containers: - name: busybox image: busybox:1.30 command: ["/bin/sh","-c","while true;do echo pod2 >> /root/out.txt; sleep 10; done;"] volumeMounts: - name: volume mountPath: /root/ volumes: - name: volume persistentVolumeClaim: claimName: pvc2 readOnly: false
建立並檢視
# 建立pod [root@master ~]# kubectl create -f pods.yaml # 檢視pod [root@master ~]# kubectl get pods -n dev -o wide # 檢視pvc [root@master ~]# kubectl get pvc -n dev -o wide # 檢視pv [root@master ~]# kubectl get pv -n dev -o wide # 檢視nfs中的檔案儲存 [root@master ~]# tail -f /root/data/pv1/out.txt [root@master ~]# tail -f /root/data/pv2/out.txt [root@master ~]# tail -f /root/data/pv3/out.txt
生命週期
PVC和PV是一一對應的，PV和PVC之間的相互作用遵循以下生命週期：
- 資源供應：管理員手動建立底層儲存和PV
- 資源繫結：使用者建立PVC，kubernetes負責根據PVC的宣告去尋找PV，並繫結
在使用者定義好PVC之後，系統將根據PVC對儲存資源的請求在已存在的PV中選擇一個滿足條件的
- 一旦找到，就將該PV與使用者定義的PVC進行繫結，使用者的應用就可以使用這個PVC了
- 如果找不到，PVC則會無限期處於Pending狀態，直到等到系統管理員建立了一個符合其要求的PV
PV一旦繫結到某個PVC上，就會被這個PVC獨佔，不能再與其他PVC進行綁定了
- 資源使用：使用者可在pod中像volume一樣使用pvc Pod使用Volume的定義，將PVC掛載到容器內的某個路徑進行使用。 - 資源釋放：使用者刪除pvc來釋放pv 當儲存資源使用完畢後，使用者可以刪除PVC，與該PVC繫結的PV將會被標記為“已釋放”，但還不能立刻與其他PVC進行繫結。通過之前PVC寫入的資料可能還被留在儲存裝置上，只有在清除之後該PV才能再次使用。 - 資源回收：kubernetes根據pv設定的回收策略進行資源的回收 對於PV，管理員可以設定回收策略，用於設定與之繫結的PVC釋放資源之後如何處理遺留資料的問題。只有PV的儲存空間完成回收，才能供新的PVC繫結和使用
參考
黑馬B站k8s課程https://www.bilibili.com/video/BV1Qv41167ck/
https://gitee.com/yooome/golang/blob/main/k8s%E8%AF%A6%E7%BB%86%E6%95%99%E7%A8%8B-%E8%B0%83%E6%95%B4%E7%89%88/k8s%E8%AF%A6%E7%BB%86%E6%95%99%E7%A8%8B.md
https://www.yuque.com/fairy-era/yg511q/xyqxge