Kubernetes v1.31：透過快取一致性讀取加速叢集效能
Kubernetes 以其強大的容器化應用程式協調而聞名，但隨著叢集規模的擴大，對控制平面的需求可能會成為瓶頸。一個關鍵的挑戰是確保從 etcd 資料儲存進行強一致性讀取，這需要資源密集型的仲裁讀取。
今天，Kubernetes 社群很高興宣布一項重大改進：來自快取的最終一致性讀取，在 Kubernetes v1.31 中升級為 Beta 版。
為什麼最終一致性讀取很重要
最終一致性讀取對於確保 Kubernetes 組件能夠準確了解最新的叢集狀態至關重要。保證最終一致性讀取對於維護 Kubernetes 操作的準確性和可靠性至關重要，使組件能夠根據最新的資訊做出明智的決策。在大型叢集中，擷取和處理這些資料可能成為效能瓶頸，尤其是對於涉及篩選結果的請求。雖然 Kubernetes 可以直接在 etcd 內按命名空間篩選資料，但任何其他按標籤或欄位選擇器的篩選都需要從 etcd 擷取整個資料集，然後由 Kubernetes API 伺服器在記憶體中篩選。這對於 kubelet 等組件尤其影響重大，kubelet 只需要列出排程到其節點的 Pod，但先前需要 API 伺服器和 etcd 處理叢集中的所有 Pod。
突破：有信心的快取
Kubernetes 長期以來一直使用監看快取來最佳化讀取操作。監看快取儲存叢集狀態的快照，並透過 etcd 監看接收更新。然而，到目前為止，它無法直接提供最終一致性讀取，因為無法保證快取已充分更新。
來自快取的最終一致性讀取功能透過利用 etcd 的 progress notifications 機制來解決此問題。這些通知告知監看快取其資料相對於 etcd 的目前程度。當請求最終一致性讀取時，系統首先檢查監看快取是否為最新狀態。如果快取不是最新狀態，系統會查詢 etcd 的進度通知，直到確認快取已充分更新。準備就緒後，讀取會直接從快取有效率地提供，這可以顯著提高效能，尤其是在需要從 etcd 擷取大量資料的情況下。這使得可以從快取提供篩選資料的請求，而只需從 etcd 讀取最少的元資料。
重要注意事項： 若要從此功能中受益，您的 Kubernetes 叢集必須執行 etcd 版本 3.4.31+ 或 3.5.13+。對於較舊的 etcd 版本，Kubernetes 將自動回退到直接從 etcd 提供最終一致性讀取。
您會注意到的效能提升
這個看似簡單的變更對 Kubernetes 效能和可擴展性產生了深遠的影響
- 降低 etcd 負載： Kubernetes v1.31 可以從 etcd 卸載工作，釋放資源用於其他關鍵操作。
- 更低的延遲： 從快取提供讀取比從 etcd 擷取和處理資料快得多。這轉化為組件更快的響應，從而提高整體叢集響應能力。
- 改進的可擴展性： 具有數千個節點和 Pod 的大型叢集將看到最顯著的提升，因為 etcd 負載的減少允許控制平面處理更多請求，而不會犧牲效能。
5k 節點可擴展性測試結果： 在最近對 5,000 個節點叢集進行的可擴展性測試中，啟用來自快取的最終一致性讀取帶來了令人印象深刻的改進
- kube-apiserver CPU 使用率降低 30%
- etcd CPU 使用率降低 25%
- Pod LIST 請求延遲的第 99 個百分位數最多降低 3 倍（從 5 秒降至 1.5 秒）
下一步是什麼？
隨著升級到 Beta 版，預設啟用來自快取的最終一致性讀取，為所有執行支援的 etcd 版本的 Kubernetes 使用者提供無縫的效能提升。
我們的旅程並未在此結束。Kubernetes 社群正在積極探索監看快取中的分頁支援，這將在未來釋放更多效能最佳化。
開始使用
升級到 Kubernetes v1.31 並確保您使用 etcd 版本 3.4.31+ 或 3.5.13+ 是體驗來自快取的最終一致性讀取優勢的最簡單方法。如果您有任何問題或意見回饋，請隨時與 Kubernetes 社群聯繫。
讓我們知道 來自快取的最終一致性讀取 如何改變您的 Kubernetes 體驗！
特別感謝 @ah8ad3 和 @p0lyn0mial 對此功能的貢獻！