儲存容量
儲存容量是有限的,並且可能因 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 使用多個卷:一個卷可能已經在拓撲片段中建立,而該片段沒有足夠的容量用於另一個卷。需要人工干預才能從中恢復,例如透過增加容量或刪除已建立的卷。
下一步
- 有關設計的更多資訊,請參閱Pod 排程儲存容量限制 KEP。