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

Kubernetes 1.6 的可擴充套件性更新：5000 節點和 150000 Pod 叢集

作者：Wojciech Tyczynski (Google) |

編者注：本文是關於 Kubernetes 1.6 新功能的一系列深度文章的一部分

去年夏天，我們分享了 Kubernetes 可伸縮性的更新，此後我們一直在努力工作，並自豪地宣佈 Kubernetes 1.6 可以處理 5,000 個節點和多達 150,000 個 Pod 的叢集。此外，這些叢集的端到端 Pod 啟動時間甚至優於 1.3 版本中之前的 2,000 節點叢集；API 呼叫的延遲也符合一秒鐘的 SLO。

在這篇部落格文章中，我們回顧了我們在測試中監控的指標，並描述了 Kubernetes 1.6 的效能結果。我們還將討論為了實現這些改進所做的更改，以及我們未來版本在系統可伸縮性方面的計劃。

X 節點叢集——這意味什麼？

既然 Kubernetes 1.6 已經發布，現在是時候回顧一下我們說“支援”X 節點叢集意味著什麼了。正如在之前的部落格文章中詳細描述的那樣，我們目前有兩個與效能相關的服務水平目標 (SLO)：

  • API 響應性：99% 的所有 API 呼叫在不到 1 秒內返回
  • Pod 啟動時間：99% 的 Pod 及其容器（使用預拉取映象）在 5 秒內啟動。與以前一樣，可以執行比所宣告支援的 5,000 節點叢集更大的部署（並且使用者已經這樣做了），但效能可能會下降，並且可能無法滿足我們上面定義的嚴格 SLO。

我們知道這些 SLO 的範圍有限。系統中有許多方面它們沒有涉及到。例如，我們不測量作為服務一部分的新 Pod 在啟動後多久可以透過服務 IP 地址訪問。如果您正在考慮使用大型 Kubernetes 叢集，並且有我們的 SLO 未涵蓋的效能要求，請聯絡 Kubernetes 可伸縮性 SIG，以便我們幫助您瞭解 Kubernetes 是否已準備好處理您的工作負載。

即將釋出的 Kubernetes 版本中，與可伸縮性相關的首要任務是透過以下方式增強我們對支援 X 節點叢集的定義：

  • 最佳化現有 SLO
  • 增加更多 SLO（將涵蓋 Kubernetes 的各個領域，包括網路）

Kubernetes 1.6 在大規模下的效能指標

那麼 Kubernetes 1.6 在大型叢集中的效能如何呢？下圖顯示了 2000 節點和 5000 節點叢集的端到端 Pod 啟動延遲。為了進行比較，我們還展示了 Kubernetes 1.3 的相同指標，該指標釋出在我們之前的可伸縮性部落格文章中，描述了對 2000 節點叢集的支援。正如您所看到的，與 Kubernetes 1.3 在 2000 節點下的情況相比，Kubernetes 1.6 在 2000 節點和 5000 節點下都具有更好的 Pod 啟動延遲 [1]。

下一張圖顯示了 5000 節點 Kubernetes 1.6 叢集的 API 響應延遲。所有百分位的延遲都小於 500ms，甚至 90 百分位也小於大約 100ms。

我們是如何做到的？

在過去九個月（自上一篇可伸縮性部落格文章以來），Kubernetes 中有大量與效能和可伸縮性相關的更改。在這篇文章中，我們將重點介紹其中兩個最大的更改，並簡要列舉其他一些更改。

etcd v3
在 Kubernetes 1.6 中，我們將預設儲存後端（儲存整個叢集狀態的鍵值儲存）從 etcd v2 切換到 etcd v3。這項過渡的初步工作始於 1.3 版本週期。您可能會想，既然有以下原因，為什麼我們花了這麼長時間：

  • etcd 支援 v3 API 的第一個穩定版本於 2016 年 6 月 30 日宣佈

  • 新的 API 是與 Kubernetes 團隊共同設計的，旨在支援我們的需求（從功能和可伸縮性角度）

  • etcd v3 與 Kubernetes 的整合在 etcd v3 釋出時大部分已經完成（實際上 CoreOS 使用 Kubernetes 作為新 etcd v3 API 的概念驗證），結果發現有很多原因。我們將在下面描述最重要的原因。

  • 以不向後相容的方式更改儲存，如 etcd v2 到 v3 遷移的情況，是一個很大的更改，因此我們需要一個強有力的理由。我們在 9 月找到了這個理由，當時我們確定如果我們繼續使用 etcd v2，我們將無法擴充套件到 5000 節點叢集（kubernetes/32361 中包含一些相關討論）。特別是，etcd v2 中的 watch 實現未能擴充套件。在 5000 節點叢集中，我們需要能夠每秒向單個觀察者傳送至少 500 個 watch 事件，這在 etcd v2 中是不可能實現的。

  • 一旦我們有了實際升級到 etcd v3 的強烈動機，我們就開始對其進行徹底測試。正如您可能預料的那樣，我們發現了一些問題。Kubernetes 中有一些小錯誤，此外我們還要求 etcd v3 的 watch 實現進行效能改進（watch 是 etcd v2 中我們主要瓶頸）。這導致了 3.0.10 etcd 補丁版本。

  • 一旦這些更改完成，我們確信*新* Kubernetes 叢集將與 etcd v3 配合使用。但遷移*現有*叢集的巨大挑戰仍然存在。為此，我們需要自動化遷移過程，徹底測試底層 CoreOS etcd 升級工具，並制定從 v3 回滾到 v2 的應急計劃。但最終，我們相信它應該能成功。

將儲存資料格式切換為 protobuf
在 Kubernetes 1.3 版本中，我們啟用了 protobufs 作為 Kubernetes 元件與 API 伺服器通訊的資料格式（同時繼續支援 JSON）。這為我們帶來了巨大的效能提升。

然而，我們仍然使用 JSON 作為資料儲存在 etcd 中的格式，儘管技術上我們已經準備好更改它。延遲此遷移的原因與我們遷移到 etcd v3 的計劃有關。現在您可能想知道此更改是如何依賴於遷移到 etcd v3 的。原因是使用 etcd v2，我們無法真正以二進位制格式儲存資料（為了解決這個問題，我們還對資料進行了 base64 編碼），而使用 etcd v3 則可以直接工作。因此，為了簡化向 etcd v3 的過渡並避免在過渡過程中對 etcd 中儲存的資料進行一些複雜的轉換，我們決定等到遷移到 etcd v3 儲存後端完成後再切換儲存資料格式為 protobuf。

其他最佳化
在過去三個版本中，我們對 Kubernetes 程式碼庫進行了數十項最佳化，包括：

  • 最佳化排程器（這使排程吞吐量提高了 5-10 倍）
  • 將所有控制器切換到使用共享 informers 的新推薦設計，這降低了 controller-manager 的資源消耗——詳情請參閱此文件
  • 最佳化 API 伺服器中的單個操作（轉換、深複製、補丁）
  • 減少 API 伺服器中的記憶體分配（這顯著影響 API 呼叫的延遲） 我們要強調的是，我們在過去幾個版本乃至整個專案歷史中完成的最佳化工作，是來自整個 Kubernetes 社群的眾多不同公司和個人共同努力的結果。

下一步是什麼？

人們經常問我們將在多大程度上改進 Kubernetes 的可伸縮性。目前，我們沒有計劃在未來幾個版本中將可伸縮性提高到 5000 節點叢集（在我們的 SLO 範圍內）以上。如果您需要大於 5000 節點的叢集，我們建議使用聯合來聚合多個 Kubernetes 叢集。

然而，這並不意味著我們將停止可伸縮性和效能方面的工作。正如我們在本文開頭提到的，我們的首要任務是完善我們現有的兩個 SLO 並引入新的 SLO，這些 SLO 將涵蓋系統更多部分，例如網路。這項工作已經在可伸縮性 SIG 內部開始。我們在如何定義效能 SLO 方面取得了顯著進展，這項工作應該在下個月完成。

加入我們的努力
如果您對可伸縮性和效能感興趣，請加入我們的社群並幫助我們塑造 Kubernetes。有很多參與方式，包括：

  • 在 Kubernetes Slack 的可伸縮性頻道與我們聊天： 
  • 加入我們的特殊興趣小組 SIG-Scalability，該小組每週四太平洋時間上午 9:00 開會。感謝您的支援和貢獻！在此閱讀更多關於 Kubernetes 1.6 新功能的深入文章。

[1] 我們正在調查為什麼 5000 節點叢集的啟動時間優於 2000 節點叢集。目前的理論是這與使用 64 核主節點執行 5000 節點實驗和使用 32 核主節點執行 2000 節點實驗有關。