儲存容量

儲存容量是有限的，並且可能因 Pod 執行的節點而異：網路附加儲存可能並非所有節點都可存取，或者儲存一開始就位於節點本機。

功能狀態： Kubernetes v1.24 [穩定]

本頁說明 Kubernetes 如何追蹤儲存容量，以及排程器如何使用該資訊將 Pod 排程到有足夠儲存容量來容納剩餘遺失磁碟區的節點上。如果沒有儲存容量追蹤，排程器可能會選擇沒有足夠容量佈建磁碟區的節點，並且需要多次排程重試。

開始之前

Kubernetes v1.32 包含叢集層級 API 支援，用於儲存容量追蹤。若要使用此功能，您也必須使用支援容量追蹤的 CSI 驅動程式。請查閱您使用的 CSI 驅動程式的文件，以瞭解此支援是否可用，以及如何使用它。如果您未執行 Kubernetes v1.32，請檢查該 Kubernetes 版本的文件。

API

此功能有兩個 API 擴展

  • CSIStorageCapacity 物件：這些物件由 CSI 驅動程式在安裝驅動程式的命名空間中產生。每個物件都包含一個儲存類別的容量資訊，並定義哪些節點可以存取該儲存。
  • CSIDriverSpec.StorageCapacity 欄位：當設定為 true 時，Kubernetes 排程器將考量使用 CSI 驅動程式的磁碟區的儲存容量。

排程

在下列情況下，Kubernetes 排程器會使用儲存容量資訊：

  • Pod 使用尚未建立的磁碟區，
  • 該磁碟區使用參考 CSI 驅動程式並使用 WaitForFirstConsumer 磁碟區繫結模式的 StorageClass，以及
  • 驅動程式的 CSIDriver 物件已將 StorageCapacity 設定為 true。

在這種情況下，排程器只會考量具有足夠可用儲存空間的節點。此檢查非常簡單，僅將磁碟區的大小與 CSIStorageCapacity 物件中列出的容量（拓撲包含節點）進行比較。

對於具有 Immediate 磁碟區繫結模式的磁碟區，儲存驅動程式會決定在何處建立磁碟區，而與將使用該磁碟區的 Pod 無關。然後，排程器會在磁碟區建立後，將 Pod 排程到磁碟區可用的節點上。

對於 CSI 暫時性磁碟區，排程始終在不考量儲存容量的情況下進行。這是基於假設這種磁碟區類型僅由節點本機的特殊 CSI 驅動程式使用，並且不需要那裡的重要資源。

重新排程

當為具有 WaitForFirstConsumer 磁碟區的 Pod 選取節點時，該決策仍然是暫定的。下一步是要求 CSI 儲存驅動程式建立磁碟區，並提示磁碟區應該在選取的節點上可用。

由於 Kubernetes 可能已根據過時的容量資訊選擇節點，因此可能無法真正建立磁碟區。然後，節點選取會被重設，而 Kubernetes 排程器會再次嘗試為 Pod 尋找節點。

限制

儲存容量追蹤增加了排程在第一次嘗試時運作的機會，但無法保證這一點，因為排程器必須根據可能過時的資訊做出決策。通常，與沒有任何儲存容量資訊的排程相同的重試機制會處理排程失敗。

排程可能永久失敗的一種情況是 Pod 使用多個 Volume：一個 Volume 可能已在拓撲區段中建立，而該區段之後沒有足夠的容量來容納另一個 Volume。需要手動介入才能從這種情況中恢復，例如增加容量或刪除已建立的 Volume。

下一步

上次修改時間：2022 年 10 月 24 日下午 3:55 PST：KubeCon 文件衝刺：更新 content/en/docs/concepts/storage 的頁面權重。(54ecdc4896)