本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。
Kubernetes 1.3 的效能和可擴充套件性更新——2000 節點 60000 Pod 叢集
我們很榮幸地宣佈，隨著1.3 版本的釋出，Kubernetes 現在支援 2000 節點叢集，並具有更好的端到端 Pod 啟動時間。我們的 API 呼叫延遲在我們的“一秒”服務水平目標 (SLO) 範圍內，其中大多數甚至比這好一個數量級。可以執行比 2,000 節點叢集更大的部署，但效能可能會下降，並且可能無法滿足我們嚴格的 SLO。
在這篇部落格文章中，我們將討論 Kubernetes 1.3 的詳細效能結果以及我們從 1.2 版本到 1.3 版本為實現這些結果所做的更改。我們還將描述 Kubemark，這是一種效能測試工具，我們已將其整合到我們的持續測試框架中，以檢測效能和可伸縮性迴歸。
評估方法
我們已經在之前的部落格文章中描述了我們的測試場景。自 1.2 版本以來最大的變化是，在我們的 API 響應測試中，我們現在建立並使用多個名稱空間。特別是對於 2000 節點/60000 Pod 叢集測試，我們建立了 8 個名稱空間。之所以進行此更改，是因為我們相信此類超大型叢集的使用者可能會使用許多名稱空間，至少叢集中總共有 8 個名稱空間。
Kubernetes 1.3 的指標
那麼，Kubernetes 1.3 版本的效能如何？下圖顯示了 2000 和 1000 節點叢集的端到端 Pod 啟動延遲。為了進行比較，我們顯示了 Kubernetes 1.2 在 1000 節點叢集中的相同指標。
我們是如何實現這些改進的？
我們在 Kubernetes 1.3 中為可伸縮性所做的最大改變是為 API 添加了一種高效的基於 Protocol Buffer 的序列化格式，作為 JSON 的替代方案。它主要用於 Kubernetes 控制平面元件之間的通訊，但所有 API 伺服器客戶端都可以使用此格式。所有 Kubernetes 控制平面元件現在都使用它進行通訊，但系統繼續支援 JSON 以實現向後相容性。
我們尚未將 etcd 中儲存叢集狀態的格式更改為 Protocol Buffers，因為我們仍在研究升級機制。但我們非常接近完成這項工作，預計將在 Kubernetes 1.4 中將儲存格式切換到 Protocol Buffers。我們的實驗表明，這應該會將 Pod 啟動端到端延遲再降低 30%。
我們如何大規模測試 Kubernetes？
啟動具有 2000 個節點的叢集既昂貴又耗時。雖然我們每個版本至少需要這樣做一次以收集真實世界的效能和可伸縮性資料，但我們還需要一種更輕量級的機制，可以讓我們快速評估不同效能改進的想法，並且我們可以持續執行以檢測效能迴歸。為了解決這一需求，我們建立了一個名為“Kubemark”的工具。
什麼是“Kubemark”？
Kubemark 是一種效能測試工具，允許使用者在模擬叢集上執行實驗。我們用它來衡量大型叢集的效能。
Kubemark 叢集由兩部分組成：一個執行正常主元件的真實主節點，以及一組“空心”節點。“空心”字首表示對元件的實現/例項化，其中一些“移動部件”被模擬出來。最好的例子是 hollow-kubelet，它假裝是一個普通的 Kubelet，但不會啟動任何容器或掛載任何卷。它只是聲稱它會這樣做，因此從主元件的角度來看，它的行為就像一個真實的 Kubelet。
由於我們希望 Kubemark 叢集儘可能接近真實叢集，我們使用注入了假 Docker 客戶端的真實 Kubelet 程式碼。同樣，hollow-proxy（KubeProxy 等效）透過注入無操作 Proxier 介面（以避免修改 iptables）來重用真實的 KubeProxy 程式碼。
多虧了這些更改
- 許多空心節點可以在一臺機器上執行，因為它們不會修改它們執行的環境
- 在沒有真實容器執行且不需要容器執行時（例如 Docker）的情況下，我們可以在一臺單核機器上執行多達 14 個空心節點。
- 然而，空心節點對 API 伺服器產生的負載與它們的“完整”對應物大致相同，因此它們為效能測試提供了真實的負載 [唯一的根本區別是我們沒有模擬現實中可能發生的任何錯誤（例如，失敗的容器）——未來框架中新增對此的支援是一個潛在的擴充套件]
我們如何設定 Kubemark 叢集？
為了建立 Kubemark 叢集，我們利用 Kubernetes 本身提供的強大功能——我們在 Kubernetes 上執行 Kubemark 叢集。讓我們詳細描述一下。
為了建立 N 節點 Kubemark 叢集，我們
- 建立一個常規的 Kubernetes 叢集，我們可以在其中執行 N 個空心節點 [例如，要建立 2000 節點 Kubemark 叢集，我們建立一個包含 22 個 8 核節點的常規 Kubernetes 叢集]
- 建立一個專用虛擬機器，我們將在其中啟動 Kubemark 叢集的所有主元件 (etcd、apiserver、controllers、scheduler 等)。
- 在基礎 Kubernetes 叢集上排程 N 個“空心節點”Pod。這些空心節點配置為與在專用虛擬機器上執行的 Kubemark API 伺服器通訊
- 最後，我們透過在基礎叢集上排程外掛 Pod（目前只有 Heapster）並配置它們與 Kubemark API 伺服器通訊來建立它們。完成此操作後，您將擁有一個可用的 Kubemark 叢集，您可以在其上執行您的（效能）測試。我們有在 Google Compute Engine (GCE) 上完成所有這些的指令碼。有關更多詳細資訊，請檢視我們的指南。
這裡值得一提的是，在執行 Kubemark 的同時，我們也在測試 Kubernetes 的正確性。顯然，如果其下的基礎 Kubernetes 叢集無法正常工作，您的 Kubemark 叢集也無法正常工作。
真實叢集與 Kubemark 中測量的效能
至關重要的是，Kubemark 叢集的效能與真實叢集的效能大多相似。對於 Pod 啟動端到端延遲，如下圖所示，差異可以忽略不計
對於 API 響應，差異更大，但通常小於 2 倍。但是，趨勢完全相同：真實叢集中的改進/迴歸在 Kubemark 的指標中顯示為相似的百分比下降/增加。
我們將繼續改進 Kubernetes 的效能和可伸縮性。在這篇部落格文章中，我們
展示了 1.3 版本可擴充套件到 2000 個節點，同時滿足了我們的響應 SLO
解釋了我們為改進 1.2 版本的可伸縮性所做的主要更改，以及
描述了 Kubemark，我們的模擬框架，它允許我們快速評估程式碼更改對效能的影響，無論是在試驗效能改進想法時，還是作為我們持續測試基礎設施的一部分來檢測迴歸。
請加入我們的社群，幫助我們構建 Kubernetes 的未來！如果您對可伸縮性特別感興趣，請透過以下方式參與：
- 在我們的 Slack 頻道上與我們聊天
- 加入可伸縮性特別興趣小組，該小組每週四太平洋時間上午 9 點在此SIG-Scale Hangout上舉行會議
有關 Kubernetes 專案的更多資訊，請訪問 kubernetes.io 並在 Twitter 上關注我們 @Kubernetesio。