儲存容量

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

特性狀態: Kubernetes v1.24 [stable]

本頁面描述了 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 使用多個卷:一個卷可能已經在拓撲片段中建立,而該片段沒有足夠的容量用於另一個卷。需要人工干預才能從中恢復,例如透過增加容量或刪除已建立的卷。

下一步

上次修改於 2022 年 10 月 24 日太平洋標準時間下午 3:55:KubeCon Docs Sprint:更新 content/en/docs/concepts/storage 的頁面權重。(54ecdc4896)