儲存容量

儲存容量是有限的，並且可能因 Pod 執行的節點而異：網路附加儲存可能無法被所有節點訪問，或者儲存一開始就本地於某個節點。

本頁面描述了 Kubernetes 如何跟蹤儲存容量以及排程器如何使用這些資訊將Pod 排程到具有足夠儲存容量的節點上，以滿足剩餘缺失卷的需求。如果沒有儲存容量跟蹤，排程器可能會選擇一個沒有足夠容量來供應卷的節點，這將需要多次排程重試。

準備工作

Kubernetes v1.34 包含對儲存容量跟蹤的叢集級 API 支援。要使用此功能，你還必須使用支援容量跟蹤的 CSI 驅動。請查閱你使用的 CSI 驅動的文件，以瞭解此支援是否可用，以及如果可用，如何使用它。如果你未執行 Kubernetes v1.34，請查閱該版本 Kubernetes 的文件。

API

此功能有兩個 API 擴充套件

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

排程

如果以下條件成立，Kubernetes 排程器將使用儲存容量資訊

• Pod 使用尚未建立的卷，
• 該卷使用引用 CSI 驅動並使用 WaitForFirstConsumer 卷繫結模式的StorageClass，並且
• 驅動的 CSIDriver 物件將 StorageCapacity 設定為 true。

在這種情況下，排程器只考慮為 Pod 提供的具有足夠可用儲存的節點。此檢查非常簡單，只將卷的大小與包含該節點的拓撲的 CSIStorageCapacity 物件中列出的容量進行比較。

對於採用 Immediate 卷繫結模式的卷，儲存驅動器獨立於將使用該卷的 Pod 決定在何處建立卷。然後，排程器在卷建立後將 Pod 排程到卷可用的節點上。

對於CSI 臨時卷，排程始終不考慮儲存容量。這是基於以下假設：這種卷型別僅由節點本地的特殊 CSI 驅動使用，並且不需要那裡的大量資源。

重新排程

當為具有 WaitForFirstConsumer 卷的 Pod 選擇了節點時，該決定仍然是暫定的。下一步是請求 CSI 儲存驅動器建立卷，並提示該卷應在選定的節點上可用。

由於 Kubernetes 可能會根據過時的容量資訊選擇節點，因此卷可能無法實際建立。然後，節點選擇將被重置，Kubernetes 排程器將再次嘗試為 Pod 查詢節點。

限制

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

一種可能導致排程永久失敗的情況是 Pod 使用多個卷：一個卷可能已經在拓撲片段中建立，而該片段沒有足夠的容量用於另一個卷。需要人工干預才能從中恢復，例如透過增加容量或刪除已建立的卷。

下一步

• 有關設計的更多資訊，請參閱Pod 排程儲存容量限制 KEP。