本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。
Kubernetes 1.23：防止在亂序刪除時出現 PersistentVolume 洩漏
PersistentVolume（簡稱 PV）與回收策略相關聯。回收策略用於確定儲存後端在刪除 PV 時需要採取的操作。當回收策略為 Delete 時，預期儲存後端會釋放為 PV 分配的儲存資源。實質上，回收策略需要在 PV 刪除時得到遵守。
透過最近釋出的 Kubernetes v1.23，一個 Alpha 功能允許您配置叢集以這種方式執行並遵守配置的回收策略。
在以前的 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 工具不會將控制權返回給 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 已刪除，但底層儲存資源未刪除，需要手動移除。
總而言之，與 Persistent Volume 關聯的回收策略在某些情況下會被忽略。對於 Bound PV-PVC 對，PV-PVC 刪除的順序決定了是否遵守 PV 回收策略。如果 PVC 首先刪除，則回收策略會得到遵守；但是，如果在刪除 PVC 之前刪除 PV，則不執行回收策略。由於這種行為，外部基礎設施中關聯的儲存資產不會被移除。
Kubernetes v1.23 中的 PV 回收策略
新行為確保當用戶手動刪除 PV 時，底層儲存物件會從後端刪除。
如何啟用新行為？
要使用新行為，您必須已將叢集升級到 Kubernetes 的 v1.23 版本。您需要確保正在執行 CSI external-provisioner 版本 4.0.0 或更高版本。您還必須為 external-provisioner 和 kube-controller-manager 啟用 HonorPVReclaimPolicy 功能門控。
如果您不使用 CSI 驅動程式與儲存後端整合，則此修復不可用。Kubernetes 專案目前沒有計劃修復樹記憶體儲驅動程式的錯誤：這些樹內驅動程式的未來是棄用並遷移到 CSI。
它是如何工作的？
新行為是透過在新的和現有 PV 上新增終結器 external-provisioner.volume.kubernetes.io/finalizer 來實現的，該終結器僅在後端儲存被刪除後才移除。
一個帶有終結器的 PV 示例，注意終結器列表中的新終結器
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
終結器的存在會阻止 PV 物件從叢集中移除。如前所述，終結器僅在 PV 物件成功從儲存後端刪除後才從 PV 物件中移除。要了解有關終結器的更多資訊，請參閱使用終結器控制刪除。
CSI 遷移的卷呢？
此修復也適用於 CSI 遷移的卷。但是，當在 1.23 上啟用 HonorPVReclaimPolicy 功能且停用 CSI 遷移時，如果 PV 物件存在終結器，則會將其移除。
一些注意事項
- 此修復僅適用於 CSI 卷和已遷移的卷。樹內卷將表現出舊行為。
- 此修復作為 Alpha 功能引入到 external-provisioner 中，位於功能門控
HonorPVReclaimPolicy下。此功能預設停用，需要顯式啟用。
參考資料
我如何參與？
Kubernetes Slack 頻道 SIG Storage 通訊渠道是聯絡 SIG Storage 和遷移工作組團隊的絕佳媒介。
特別感謝以下人員的深刻見解、周詳考慮和寶貴貢獻
- Jan Šafránek (jsafrane)
- Xing Yang (xing-yang)
- Matthew Wong (wongma7)
有興趣參與 CSI 或 Kubernetes 儲存系統任何部分設計和開發的人士，請加入 Kubernetes 儲存特別興趣小組 (SIG)。我們正在快速成長，並始終歡迎新的貢獻者。