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

本機儲存：儲存容量追蹤、分散式佈建和通用暫時性磁碟區進入 Beta 階段

作者：Patrick Ohly (Intel) | 2021 年 4 月 14 日星期三

Kubernetes 中的「通用臨時卷」和「儲存容量追蹤」功能將在 Kubernetes 1.21 中升級為 Beta 版。結合 CSI external-provisioner 中的分散式佈建支援，管理節點本機儲存的容器儲存介面 (CSI) 驅動程式的開發和部署變得更加容易。

這篇部落格文章說明了此類驅動程式過去的運作方式，以及如何使用這些功能來簡化驅動程式。

我們正在解決的問題

有些本機儲存的驅動程式，例如適用於傳統磁碟的 TopoLVM 和適用於持久記憶體的 PMEM-CSI。它們可以運作，並且今天也已準備好在較舊的 Kubernetes 版本上使用，但使其成為可能並非易事。

所需的核心組件

第一個問題是卷佈建：它由 Kubernetes 控制平面處理。某些組件必須對PersistentVolumeClaims (PVC) 做出反應並建立卷。通常，這由 CSI external-provisioner 的中央部署和然後連接到儲存底板的 CSI 驅動程式組件處理。但是對於本機儲存，沒有這樣的底板。

TopoLVM 透過讓其不同組件透過 Kubernetes API 伺服器相互通訊來解決此問題，方法是建立自訂資源並對其做出反應。因此，儘管 TopoLVM 基於 CSI，這是一個獨立於特定容器協調器的標準，但 TopoLVM 僅適用於 Kubernetes。

PMEM-CSI 透過 gRPC 呼叫通訊建立了自己的儲存底板。保護該通訊取決於 TLS 憑證，這使得驅動程式部署更加複雜。

告知 Pod 排程器容量

下一個問題是排程。當卷的建立獨立於 Pod（「立即綁定」）時，CSI 驅動程式必須選擇一個節點，而無需了解任何將要使用它的 Pod。然後，拓撲資訊會強制這些 Pod 在建立卷的節點上執行。如果 RAM 或 CPU 等其他資源在那裡耗盡，則 Pod 無法啟動。可以透過在 StorageClass 中設定卷建立旨在等待第一個使用卷的 Pod (volumeBinding: WaitForFirstConsumer) 來避免這種情況。在該模式下，Kubernetes 排程器會根據其他約束暫時選擇一個節點，然後要求 external-provisioner 建立一個卷，使其可以在那裡使用。如果本機儲存已耗盡，則佈建器可以要求進行另一個排程輪次。但是，如果沒有有關可用容量的資訊，排程器可能會始終選擇同一個不合適的節點。

TopoLVM 和 PMEM-CSI 都透過排程器擴展器解決了這個問題。這可行，但是當部署驅動程式時，很難配置，因為 kube-scheduler 和驅動程式之間的通訊非常依賴於叢集的設定方式。

重新排程

本機儲存的常見用例是暫存空間。對於該用例，比持久卷更適合的是臨時卷，這些臨時卷是為 Pod 建立的，並與 Pod 一起銷毀。用於支援 CSI 驅動程式的臨時卷的初始 API（因此稱為「CSI 臨時卷」）是為輕量級卷設計的，其中卷建立不太可能失敗。卷建立發生在 Pod 已永久排程到節點之後，這與傳統的佈建（在將 Pod 排程到節點之前嘗試卷建立）形成對比。必須修改 CSI 驅動程式以支援「CSI 臨時卷」，TopoLVM 和 PMEM-CSI 都已完成此操作。但是由於 Kubernetes 中該功能的設計，如果節點上的儲存容量耗盡，Pod 可能會永久卡住。排程器擴展器嘗試避免這種情況，但無法 100% 可靠。

Kubernetes 1.21 中的增強功能

分散式佈建

從 external-provisioner v2.1.0 開始，該版本是為 Kubernetes 1.20 發布的，佈建可以由與每個節點上的 CSI 驅動程式一起部署的 external-provisioner 實例處理，然後協作佈建卷（「分散式佈建」）。不再需要中央組件，因此至少對於佈建而言，節點之間無需通訊。

儲存容量追蹤

排程器擴展器仍然需要某種方式來了解每個節點上的容量。當 PMEM-CSI 在 v0.9.0 中切換到分散式佈建時，這是透過查詢本機驅動程式容器公開的指標資料來完成的。但是，對於使用者來說，最好也完全消除對排程器擴展器的需求，因為驅動程式部署變得更簡單。儲存容量追蹤，在 1.19 中引入並在 Kubernetes 1.21 中升級為 Beta 版，實現了這一目標。它的工作原理是在 CSIStorageCapacity 物件中發布有關容量的資訊。然後，排程器本身會使用該資訊來篩選掉不合適的節點。由於資訊可能不是完全最新的，因此 Pod 仍然可能被分配到儲存空間不足的節點，只是可能性較小，並且一旦資訊得到刷新，Pod 的下一次排程嘗試應該會更好。

通用臨時卷

因此，CSI 驅動程式仍然需要能夠從錯誤的排程決策中恢復，這件事被證明對於「CSI 臨時卷」來說是不可能實現的。「通用臨時卷」，這是另一個在 1.21 中升級為 Beta 版的功能，沒有該限制。此功能新增了一個控制器，該控制器將建立和管理生命週期與 Pod 相同的 PVC，因此正常的恢復機制也適用於它們。現有的儲存驅動程式將能夠處理這些 PVC，而無需任何新的邏輯來處理這種新情況。

已知限制

通用臨時卷和儲存容量追蹤都會增加 API 伺服器上的負載。這是否成為問題在很大程度上取決於工作負載的類型，尤其是有多少 Pod 具有卷以及這些卷需要建立和銷毀的頻率。

沒有嘗試對排程決策如何影響儲存容量進行建模。那是因為效果可能會因儲存系統如何處理儲存而異。其影響是，即使只有足夠一個 Pod 的容量，多個具有未綁定卷的 Pod 也可能被分配到同一個節點。排程應該會恢復，但如果排程器更了解儲存，則會更有效率。

由於儲存容量由正在執行的 CSI 驅動程式發布，並且叢集自動擴展器需要有關尚未建立的節點的資訊，因此目前它不會為需要卷的 Pod 擴展叢集。有一個關於如何提供該資訊的想法，但在該領域還需要做更多工作。

目前不支援分散式快照和調整大小。應該可以調整各自的 sidecar，並且已經為 external-snapshotter 和 external-resizer 開放了追蹤問題，它們只需要一些志願者。

對於具有多個卷的 Pod，從錯誤的排程決策中恢復可能會失敗，尤其是當這些卷是節點本機卷時：如果可以建立一個卷，然後儲存空間不足以建立另一個卷，則第一個卷會繼續存在並強制排程器將 Pod 放置到該卷的節點上。有一個關於如何處理這個問題的想法，回滾卷的佈建，但這僅處於非常早期的集思廣益階段，甚至還不是合併的 KEP。目前，最好避免建立具有多個持久卷的 Pod。

啟用新功能和後續步驟

隨著該功能在 1.21 版本中進入 Beta 版，無需採取其他操作即可啟用它。通用臨時卷也適用於 CSI 驅動程式，無需更改。如需更多資訊，請參閱文件和關於它的先前部落格文章。API 在 Alpha 版和 Beta 版之間完全沒有改變。

對於其他兩個功能，external-provisioner 文件說明了 CSI 驅動程式開發人員必須如何更改其驅動程式的部署方式，以支援儲存容量追蹤和分散式佈建。這兩個功能是獨立的，因此僅啟用其中一個功能是可以的。

如果您正在使用這些新功能，SIG Storage 很高興收到您的回饋。我們可以透過電子郵件、Slack（頻道 #sig-storage）和定期 SIG 會議與我們聯繫。對您的工作負載的描述將非常有助於驗證設計決策、設定效能測試，並最終將這些功能升級為 GA。

致謝

非常感謝社群成員為這些功能做出貢獻或提供回饋，包括 SIG Scheduling、SIG Auth 和當然還有 SIG Storage 的成員！