Kubernetes 1.31：防止在刪除順序錯亂時發生 PersistentVolume 洩漏
PersistentVolume（或簡稱 PV）與回收策略相關聯。回收策略用於決定在刪除綁定到 PV 的 PVC 時，儲存後端需要採取的動作。當回收策略為 Delete 時，預期儲存後端會釋放為 PV 分配的儲存資源。本質上，回收策略需要在刪除 PV 時被遵守。
在最近的 Kubernetes v1.31 版本中，一個 Beta 功能讓您可以配置您的叢集以這種方式運作，並遵守配置的回收策略。
先前的 Kubernetes 版本中回收是如何運作的？
PersistentVolumeClaim（或簡稱 PVC）是用戶對儲存的請求。如果找到新建立的 PV 或匹配的 PV，則 PV 和 PVC 被視為已綁定。PV 本身由儲存後端分配的卷支持。
通常，如果要刪除卷，則預期刪除綁定的 PV-PVC 配對的 PVC。但是，在刪除 PVC 之前刪除 PV 沒有任何限制。
首先，我將示範在執行舊版 Kubernetes 的叢集上的行為。
檢索綁定到 PV 的 PVC
檢索現有的 PVC example-vanilla-block-pvc
kubectl get pvc example-vanilla-block-pvc
以下輸出顯示 PVC 及其綁定的 PV；PV 顯示在 VOLUME 欄位下
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
example-vanilla-block-pvc Bound pvc-6791fdd4-5fad-438e-a7fb-16410363e3da 5Gi RWO example-vanilla-block-sc 19s
刪除 PV
當我嘗試刪除綁定的 PV 時，kubectl 會話會被阻止，並且 kubectl 工具不會將控制權返回給 shell；例如
kubectl delete pv pvc-6791fdd4-5fad-438e-a7fb-16410363e3da
persistentvolume "pvc-6791fdd4-5fad-438e-a7fb-16410363e3da" deleted
^C
檢索 PV
kubectl get pv pvc-6791fdd4-5fad-438e-a7fb-16410363e3da
可以觀察到 PV 處於 Terminating 狀態
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pvc-6791fdd4-5fad-438e-a7fb-16410363e3da 5Gi RWO Delete Terminating default/example-vanilla-block-pvc example-vanilla-block-sc 2m23s
刪除 PVC
kubectl delete pvc example-vanilla-block-pvc
如果 PVC 成功刪除，則會看到以下輸出
persistentvolumeclaim "example-vanilla-block-pvc" deleted
叢集中的 PV 物件也會被刪除。當嘗試檢索 PV 時，將會觀察到不再找到 PV
kubectl get pv pvc-6791fdd4-5fad-438e-a7fb-16410363e3da
Error from server (NotFound): persistentvolumes "pvc-6791fdd4-5fad-438e-a7fb-16410363e3da" not found
雖然 PV 已刪除，但底層儲存資源未刪除，需要手動移除。
總結一下，與 PersistentVolume 關聯的回收策略目前在某些情況下會被忽略。對於 Bound PV-PVC 配對，PV-PVC 刪除的順序決定了是否遵守 PV 回收策略。如果先刪除 PVC，則會遵守回收策略；但是，如果在刪除 PVC 之前刪除 PV，則不會執行回收策略。由於這種行為，外部基礎架構中相關聯的儲存資產不會被移除。
Kubernetes v1.31 的 PV 回收策略
新的行為確保當使用者嘗試手動刪除 PV 時，底層儲存物件會從後端刪除。
如何啟用新行為？
若要利用新行為，您必須將叢集升級到 Kubernetes v1.31 版本，並執行 CSI external-provisioner 版本 5.0.1 或更高版本。
它是如何運作的？
對於 CSI 卷，新的行為是透過在新的和現有的 PV 上添加 finalizer external-provisioner.volume.kubernetes.io/finalizer 來實現的。只有在從後端刪除儲存後，才會移除 finalizer。 `
具有 finalizer 的 PV 範例，請注意 finalizers 清單中的新 finalizer
kubectl get pv pvc-a7b7e3ba-f837-45ba-b243-dec7d8aaed53 -o yaml
apiVersion: v1
kind: PersistentVolume
metadata:
annotations:
pv.kubernetes.io/provisioned-by: csi.vsphere.vmware.com
creationTimestamp: "2021-11-17T19:28:56Z"
finalizers:
- kubernetes.io/pv-protection
- external-provisioner.volume.kubernetes.io/finalizer
name: pvc-a7b7e3ba-f837-45ba-b243-dec7d8aaed53
resourceVersion: "194711"
uid: 087f14f2-4157-4e95-8a70-8294b039d30e
spec:
accessModes:
- ReadWriteOnce
capacity:
storage: 1Gi
claimRef:
apiVersion: v1
kind: PersistentVolumeClaim
name: example-vanilla-block-pvc
namespace: default
resourceVersion: "194677"
uid: a7b7e3ba-f837-45ba-b243-dec7d8aaed53
csi:
driver: csi.vsphere.vmware.com
fsType: ext4
volumeAttributes:
storage.kubernetes.io/csiProvisionerIdentity: 1637110610497-8081-csi.vsphere.vmware.com
type: vSphere CNS Block Volume
volumeHandle: 2dacf297-803f-4ccc-afc7-3d3c3f02051e
persistentVolumeReclaimPolicy: Delete
storageClassName: example-vanilla-block-sc
volumeMode: Filesystem
status:
phase: Bound
Finalizer 阻止從叢集中移除此 PersistentVolume。如前所述，只有在從儲存後端成功刪除後，才會從 PV 物件中移除 finalizer。若要了解更多關於 finalizer 的資訊，請參閱 使用 Finalizers 控制刪除。
同樣地，finalizer kubernetes.io/pv-controller 也會添加到動態佈建的 in-tree 外掛程式卷。
CSI 遷移卷呢？
此修復也適用於 CSI 遷移卷。
一些注意事項
此修復不適用於靜態佈建的 in-tree 外掛程式卷。
參考資料
我該如何參與？
Kubernetes Slack 頻道 SIG Storage 通訊頻道 是聯繫 SIG Storage 和遷移工作組團隊的絕佳媒介。
特別感謝以下人員的深刻見解、周全考慮和寶貴貢獻
- Fan Baofa (carlory)
- Jan Šafránek (jsafrane)
- Xing Yang (xing-yang)
- Matthew Wong (wongma7)
如果您有興趣參與 CSI 或 Kubernetes 儲存系統任何部分的設計和開發，請加入 Kubernetes 儲存特別興趣小組 (SIG)。我們正在快速成長，隨時歡迎新的貢獻者。