本篇文章已超過一年。較舊的文章可能包含過時的內容。請檢查本頁面中的資訊自發布以來是否已變得不正確。
Kubernetes 1.3 效能與擴充性更新 -- 2,000 節點 60,000 Pod 叢集
我們很榮幸宣布，隨著 1.3 版本發布，Kubernetes 現在支援 2000 個節點的叢集，並具備更優異的端對端 Pod 啟動時間。我們的 API 呼叫延遲在我們一秒鐘的 服務等級目標 (SLO) 範圍內，而且大多數甚至比這個目標還要好上一個數量級。雖然可以執行比 2,000 個節點叢集更大規模的部署，但效能可能會降低，而且可能無法達到我們嚴格的 SLO 標準。
在這篇部落格文章中，我們將討論 Kubernetes 1.3 的詳細效能結果，以及我們從 1.2 版本中所做的哪些變更以達成這些成果。我們也將介紹 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 叢集包含兩個部分：一個執行正常 master 組件的真實 master 節點，以及一組 “空心” 節點。“空心” 這個前綴表示組件的實作/實例化，其中某些 “活動部件” 被模擬出來。最佳範例是 hollow-kubelet，它假裝成一個普通的 Kubelet，但不會啟動任何容器或掛載任何磁碟區。它只是宣稱它會執行這些操作，因此從 master 組件的角度來看，它的行為就像一個真實的 Kubelet。
由於我們希望 Kubemark 叢集盡可能地與真實叢集相似，因此我們使用真實的 Kubelet 程式碼以及注入的虛擬 Docker 用戶端。同樣地，hollow-proxy (KubeProxy 的等效元件) 重複使用真實的 KubeProxy 程式碼以及注入的 no-op Proxier 介面 (以避免更動 iptables)。
感謝這些變更
- 許多空心節點可以在單一機器上執行，因為它們不會修改其運作環境
- 由於沒有真實容器在執行，而且不需要容器執行階段 (例如 Docker)，我們可以在單核心機器上最多執行 14 個空心節點。
- 然而，空心節點在 API 伺服器上產生的負載與其 “完整” 對應物大致相同，因此它們為效能測試提供了真實的負載 [唯一的基本差異在於，我們沒有模擬現實中可能發生的任何錯誤 (例如，容器故障) - 未來在框架中新增對此的支援是一項潛在的擴充功能]
我們如何設定 Kubemark 叢集？
為了建立 Kubemark 叢集，我們使用 Kubernetes 本身賦予我們的力量 - 我們在 Kubernetes 上執行 Kubemark 叢集。讓我們詳細描述這一點。
為了建立一個 N 節點 Kubemark 叢集，我們
- 建立一個常規 Kubernetes 叢集，我們可以在其中執行 N 個空心節點 [例如，為了建立 2000 個節點的 Kubemark 叢集，我們建立一個具有 22 個 8 核心節點的常規 Kubernetes 叢集]
- 建立一個專用 VM，我們在其中啟動 Kubemark 叢集的所有 master 組件 (etcd、apiserver、控制器、排程器，...)。
- 在基礎 Kubernetes 叢集上排程 N 個 “空心節點” Pod。這些空心節點配置為與在專用 VM 上執行的 Kubemark API 伺服器通訊
- 最後，我們透過在基礎叢集上排程附加元件 Pod (目前僅有 Heapster) 並配置它們與 Kubemark API 伺服器通訊，來建立附加元件 Pod。完成此操作後，您就會擁有一個可用的 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。