本文已發布超過一年。較舊的文章可能包含過時的內容。請檢查頁面中的資訊自發布以來是否已變得不正確。

Kubernetes v1.26：追溯預設儲存類別

作者：Roman Bednář (Red Hat) |

Kubernetes v1.25 版本引入了一項 Alpha 功能，以變更預設 StorageClass 指派給 PersistentVolumeClaim (PVC) 的方式。啟用此功能後，您不再需要先建立預設 StorageClass，再建立 PVC 來指派類別。此外，任何未指派 StorageClass 的 PVC 稍後都可以更新。此功能已在 Kubernetes v1.26 中升級為 Beta 版。

您可以在 Kubernetes 文件中閱讀 追溯預設 StorageClass 指派，以取得有關如何使用它的更多詳細資訊，或者您可以繼續閱讀以了解 Kubernetes 專案為何要進行此變更。

為何 StorageClass 指派需要改進

使用者可能已經熟悉類似的功能，該功能會在建立時將預設 StorageClass 指派給新的 PVC。目前由許可控制器處理。

但是，如果在建立 PVC 時未定義預設 StorageClass 怎麼辦？使用者最終會得到一個永遠不會被指派類別的 PVC。結果，將不會佈建任何儲存空間，並且 PVC 在此時會有點「卡住」。一般而言，有兩種主要情況可能會導致 PVC「卡住」並在稍後造成問題。讓我們仔細看看它們中的每一個。

變更預設 StorageClass

啟用 Alpha 功能後，管理員想要變更預設 StorageClass 時有兩個選項

  1. 在移除與 PVC 關聯的舊預設 StorageClass 之前，先建立新的 StorageClass 作為預設。這將導致在短時間內有兩個預設值。此時，如果使用者要建立一個 storageClassName 設為 null (表示預設 StorageClass) 的 PersistentVolumeClaim，則將選擇最新的預設 StorageClass 並指派給此 PVC。

  2. 先移除舊預設值，然後建立新的預設 StorageClass。這將導致在短時間內沒有預設值。隨後，如果使用者要建立一個 storageClassName 設為 null (表示預設 StorageClass) 的 PersistentVolumeClaim，則 PVC 將永遠處於 Pending 狀態。使用者將必須透過刪除 PVC 並在預設 StorageClass 可用時重新建立它來修正此問題。

叢集安裝期間的資源排序

如果叢集安裝工具需要建立需要儲存空間的資源，例如映像登錄，則很難獲得正確的排序。這是因為任何需要儲存空間的 Pod 都將依賴預設 StorageClass 的存在，如果未定義，則將無法建立。

變更了什麼

我們已變更 PersistentVolume (PV) 控制器，以將預設 StorageClass 指派給任何 storageClassName 設為 null 的未繫結 PersistentVolumeClaim。我們也修改了 API 伺服器內的 PersistentVolumeClaim 許可，以允許將值從未設定的值變更為實際的 StorageClass 名稱。

空值 storageClassName 與 storageClassName: "" - 有差別嗎？

在引入此功能之前，這些值在行為方面是相等的。任何 storageClassName 設為 null 或 "" 的 PersistentVolumeClaim 都將繫結到 storageClassName 也設為 null 或 "" 的現有 PersistentVolume 資源。

啟用此新功能後，我們希望保持此行為，但也能夠更新 StorageClass 名稱。考慮到這些限制，此功能變更了 null 的語意。如果存在預設 StorageClass，則 null 將轉換為「給我一個預設值」，而 "" 將表示「給我一個也具有 "" StorageClass 名稱的 PersistentVolume」。在沒有 StorageClass 的情況下，行為將保持不變。

總結以上內容，我們已變更 null 的語意，使其行為取決於預設 StorageClass 定義的存在與否。

下表顯示所有這些案例，以更好地描述 PVC 何時繫結以及何時更新其 StorageClass。

使用追溯預設 StorageClass 的 PVC 繫結行為
PVCstorageClassName = ""PVCstorageClassName= null
沒有預設類別PVstorageClassName = ""繫結繫結
沒有 PVstorageClassName繫結繫結
有預設類別PVstorageClassName = ""繫結類別更新
沒有 PVstorageClassName繫結類別更新

如何使用

如果您想在功能為 Alpha 版時進行測試，則需要在 kube-controller-manager 和 kube-apiserver 中啟用相關的功能閘道。使用 --feature-gates 命令列引數

--feature-gates="...,RetroactiveDefaultStorageClass=true"

試駕

如果您想查看此功能的實際運作情況並驗證它在您的叢集中運作良好，您可以嘗試以下操作

  1. 定義基本 PersistentVolumeClaim

    apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-1
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

  2. 當沒有預設 StorageClass 時，建立 PersistentVolumeClaim。PVC 將不會佈建或繫結 (除非已存在現有的、合適的 PV)，並且將保持 Pending 狀態。

    kubectl get pvc

    輸出類似於這樣

    NAME      STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
pvc-1     Pending

  3. 將一個 StorageClass 設定為預設值。

    kubectl patch sc -p '{"metadata":{"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

    輸出類似於這樣

    storageclass.storage.k8s.io/my-storageclass patched

  4. 驗證 PersistentVolumeClaims 現在已正確佈建，並已使用新的預設 StorageClass 追溯更新。

    kubectl get pvc

    輸出類似於這樣

    NAME      STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS      AGE
pvc-1     Bound    pvc-06a964ca-f997-4780-8627-b5c3bf5a87d8   1Gi        RWO            my-storageclass   87m

新指標

為了幫助您了解該功能是否按預期運作，我們還引入了一個新的 retroactive_storageclass_total 指標，以顯示 PV 控制器嘗試更新 PersistentVolumeClaim 的次數，以及 retroactive_storageclass_errors_total 以顯示這些嘗試中有多少次失敗。

參與其中

我們始終歡迎新的貢獻者，因此如果您想參與其中，可以加入我們的 Kubernetes 儲存特殊興趣小組 (SIG)。

如果您想分享意見回饋，可以在我們的 公開 Slack 頻道上進行。

特別感謝所有提供出色評論、分享寶貴見解並協助實作此功能的貢獻者 (依字母順序排列)