Kubernetes 1.6 中的可擴展性更新：5,000 個節點與 150,000 個 Pod 叢集

編輯註：這篇文章是關於 Kubernetes 1.6 新功能的深入文章系列的一部分

去年夏天，我們分享了關於 Kubernetes 可擴展性的更新，自那時以來，我們一直努力不懈，並榮幸地宣布Kubernetes 1.6 可以處理高達 150,000 個 Pod 的 5,000 節點叢集。此外，這些叢集甚至比 1.3 版本中先前的 2,000 節點叢集具有更好的端到端 Pod 啟動時間；且 API 呼叫的延遲在 1 秒 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 Scalability 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 回應延遲。所有百分位數的延遲都小於 500 毫秒，即使是第 90 個百分位數也小於約 100 毫秒。

我們是如何做到這點的？

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

etcd v3
在 Kubernetes 1.6 中，我們將預設儲存後端（儲存整個叢集狀態的鍵值儲存）從 etcd v2 切換到 etcd v3。朝此轉換的初步工作已在 1.3 版本週期中開始。您可能會想知道為什麼我們花了這麼長時間，考慮到

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

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

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

• 以向後不相容的方式更改儲存，就像 etcd v2 到 v3 的遷移一樣，是一個很大的變更，因此我們需要強有力的理由來證明其合理性。我們在 9 月找到了這個理由，當時我們確定如果繼續使用 etcd v2，我們將無法擴展到 5000 節點叢集（kubernetes/32361 包含一些相關討論）。特別是，無法擴展的是 etcd v2 中的 watch 實作。在 5000 節點叢集中，我們需要能夠每秒向單個 watcher 發送至少 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 儲存後端完成後，再將儲存資料格式切換為 protobufs。

其他最佳化
在過去的三個版本中，我們在整個 Kubernetes codebase 中進行了數十項最佳化，包括

• 最佳化排程器（從而使排程吞吐量提高了 5-10 倍）
• 將所有控制器切換到使用共用 Informer 的新建議設計，這減少了 controller-manager 的資源消耗 - 如需參考，請參閱此文件
• 最佳化 API 伺服器中的個別操作（轉換、深層複製、修補）
• 減少 API 伺服器中的記憶體分配（這會顯著影響 API 呼叫的延遲）。我們要強調的是，我們在過去幾個版本中所做的最佳化工作，以及整個專案歷史中的最佳化工作，是整個 Kubernetes 社群中許多不同公司和個人的共同努力。

接下來是什麼？

人們經常問我們在改善 Kubernetes 可擴展性方面會走多遠。目前，我們沒有計畫在接下來的幾個版本中將可擴展性提高到超過 5000 節點叢集（在我們的 SLO 範圍內）。如果您需要大於 5000 節點的叢集，我們建議使用聯邦來聚合多個 Kubernetes 叢集。

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

加入我們的行列
如果您對可擴展性和效能感興趣，請加入我們的社群，協助我們塑造 Kubernetes。有很多參與方式，包括

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

[1] 我們正在調查為什麼 5000 節點叢集的啟動時間比 2000 節點叢集更好。目前的理論是，這與使用 64 核心 master 運行 5000 節點實驗，以及使用 32 核心 master 運行 2000 節點實驗有關。

• ←上一篇
下一篇→