Kubernetes 1.24：儲存容量跟蹤現已正式可用

Kubernetes v1.24 版本將儲存容量跟蹤功能作為通用功能正式釋出。

我們已解決的問題

正如上一篇關於此功能的部落格文章中更詳細地解釋的那樣，儲存容量跟蹤允許 CSI 驅動程式釋出有關剩餘容量的資訊。kube-scheduler 然後使用這些資訊為 Pod 選擇合適的節點，當該 Pod 有尚未需要進行供應的卷時。

如果沒有這些資訊，Pod 可能會因為 kube-scheduler 必須盲目選擇並總是選擇一個無法供應卷的節點（因為 CSI 驅動程式管理的基礎儲存系統沒有足夠的剩餘容量）而無法排程到合適的節點上，從而陷入停滯。

由於 CSI 驅動程式釋出的儲存容量資訊在後續使用時可能不是最新的，因此仍可能發生選擇了最終不適用的節點的情況。卷供應會透過通知排程器需要嘗試使用不同的節點來從這種情況中恢復。

為正式釋出而進行的負載測試再次證實，在啟用儲存容量跟蹤的情況下，叢集中的所有儲存都可以被 Pod 消耗，而沒有該功能時 Pod 會卡住。

我們 尚未 解決的問題

從失敗的卷供應嘗試中恢復有一個已知限制：如果 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 的成員！

• ←上一篇
• 下一篇→