Kubernetes 1.24：儲存容量追蹤功能現已正式推出

Kubernetes v1.24 版本將儲存容量追蹤功能正式推出。

我們已解決的問題

如同先前關於此功能的部落格文章中更詳細的說明，儲存容量追蹤功能允許 CSI 驅動程式發布關於剩餘容量的資訊。然後，kube-scheduler 會使用該資訊，在 Pod 仍需要佈建磁碟區時，為 Pod 選擇合適的節點。

若沒有此資訊，Pod 可能會卡住，永遠無法排程到合適的節點，因為 kube-scheduler 必須盲目選擇，最終總是選擇無法佈建磁碟區的節點，原因是 CSI 驅動程式管理的底層儲存系統沒有足夠的剩餘容量。

由於 CSI 驅動程式發布的儲存容量資訊是在稍後的時間使用，屆時資訊可能不再是最新的，因此仍然可能發生選擇的節點最終無法運作的情況。磁碟區佈建會從中恢復，並通知排程器需要再次嘗試使用不同的節點。

為了升級到 GA 而再次進行的負載測試確認，在有儲存容量追蹤的情況下，叢集中的所有儲存空間都可以被 Pod 消耗，而在沒有儲存容量追蹤的情況下，Pods 會卡住。

我們尚未解決的問題

從失敗的磁碟區佈建嘗試中恢復有一個已知的限制：如果 Pod 使用兩個磁碟區，但只有其中一個可以佈建，那麼所有未來的排程決策都會受到已佈建磁碟區的限制。如果該磁碟區是節點本地的，而另一個磁碟區無法在那裡佈建，則 Pod 會卡住。這個問題早於儲存容量追蹤，雖然額外的資訊使其不太可能發生，但它無法在所有情況下避免，除非當然每個 Pod 只使用一個磁碟區。

在KEP 草案中提出了一個解決方案的想法：已佈建但尚未使用的磁碟區不會有任何有價值的資料，因此可以釋放並在其他地方重新佈建。SIG Storage 正在尋找有興趣繼續開發此功能的開發人員。

同樣尚未解決的是 Cluster Autoscaler 對帶有磁碟區的 Pod 的支援。對於具有儲存容量追蹤功能的 CSI 驅動程式，在PR中開發並討論了一個原型。它旨在與任意 CSI 驅動程式一起使用，但這種靈活性使其難以配置，並減慢了擴展操作：由於 autoscaler 無法模擬磁碟區佈建，它一次只能將叢集擴展一個節點，這被認為是不夠的。

因此，該 PR 未合併，並且需要 autoscaler 和 CSI 驅動程式之間更緊密耦合的不同方法。為此，需要更好地理解哪些本地儲存 CSI 驅動程式與叢集自動擴展結合使用。如果這導致新的 KEP，那麼使用者將必須在實務中試用實作，然後才能進入 Beta 版或 GA 版。因此，如果您對此主題感興趣，請聯絡 SIG Storage。

致謝

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

• ←上一篇
下一篇→