Kubernetes性能測試和發展計劃

【編者的話】Kubernetes是谷歌在2014年發起的開源容器編排框架，作者 Wojciech Tyczynski ，谷歌軟件工程師，本文主要闡述目前狀態下Kubernetes的性能測試和下一步發展計劃。

無論你的容器編排系統是多靈活多可靠，你最終還是會有些工作要做，而且你還希望它能夠完成得更快。對于大的問題，常見的方案就是投入更多的機器在這個問題上。畢竟，更多的計算=更快，對嗎？

有趣的是，投入更多節點有點像『火箭方程的暴政』（ tyranny of the rocket equation ；譯者注：根據火箭方程，并不是火箭級數越多速度就會越快），事實上，在某些系統里加入更多的機器會使你的處理變得更慢。但是，又不像火箭方程，我們可以 做的更好。Kubernetes在v1.0版本支持最多100個節點的集群，但是我們的目標是在2015年末將這個數字番10倍。這篇博文會闡述我們目前 所在的位置和我們打算如何達到下一階段的目標性能。

測量什么？

第一個需要回答的問題是Kubernetes可以管理一個多節點集群的真正含義是什么？用戶期望是它處理所有操作都“相對較快”，但是我們需要精確的定義『快』。我們基于下面兩個指標定義了性能和可擴展性的目標：

1. “API響應性”：99%的API調用響應時間小于1秒
2. “Pod啟動時間”：99%的pods（已經下好鏡像）啟動時間在5秒以內

注意，對于『Pod啟動時間』，我們明確地假設pod運行的所有鏡像都已經提前下載到將要跑機器上。在我們的試驗中，鏡像之間雖然會有很高程度的差異性，如網絡吞吐量，鏡像大小等，但這些變化幾乎不會影響Kubernetes的整體性能。

決定選擇這些指標是基于我們在Google一星期內不斷啟動20億個容器的試驗。我們明確地希望測量與面向用戶交互流（user-facing flows）的時延，因為這是我們的客戶真的關心的事。

如何測量？

為了監控性能提高量和檢測回歸性，我們搭建了持續測試的基礎設施。每2-3個小時我們會啟動一個含有100個節點的集群，并且運行我們的擴展性測 試這個集群上。我們使用一個GCE的n1-standard-4（4核，15G內存）機器作為master和多個n1-standard-1（1 核，3.75G內存）機器作為節點。

在擴展性測試中，我們只專注于滿集群情況，意思是一個滿N個節點的集群含有30*N個pods運行在集群中，從性能測試的角度來看這是非常嚴苛的場景。為了重現一個客戶可能的操作，我們按照下面的步驟運行：

1. 構建pods和replication controllers去填充集群
2. 制造一些負載，如創建或刪除多余的pods或replication controllers，縮放現有的pods或replication controllers等操作，記錄性能參數
3. 停止所有運行中的pods或replication controllers
4. 改變一些指標，檢查是否滿足我們的預期

需要強調的是測試主要部分是完成在滿集群上（每個節點30個pods，一共100個nodes），啟動一個pod在一個空集群中，即使它含有100個節點會變得更快。（譯者注：這里不太清楚作者的意思）

為了測量pod啟動時延，我們使用非常簡單的pod，只含有一個容器，運行『gcr.io/google_containers /pause:go』鏡像，鏡像啟動后就永遠休眠。容器保證已經提前被下到節點上，我們使用它作為所謂的『pod-infra-container』。

性能數據

下面的表格包含pod啟動的百分位數（第50位，第90位，第99位），在含有10%，25%，50%和100%的100個節點的集群中。

對于API響應性，下面圖片展示百分位數是第50位，第90位和第99位的API請求時延，它們是根據操作和資源類型分類的。但是，要注意的是這些仍然包括內部系統API請求，并不僅僅是由用戶發出的（這種情況下是由測試本身發出）

一些資源只出現在某些的圖片中，這是因為圖片是根據在這個操作過程中運行了什么畫出來的，例如在『PUT』這個操作中并沒有名字空間。

正如你看到的結果，我們已經領先的我們目標，在100個節點的集群里，對于一個pod啟動時間，有14%的情況是一個滿集群甚至會比99分位快5 秒鐘。有意思的是在『LIST』圖中列出pod的時間會遠遠大于其他操作，這是可以理解的，在一個滿集群中有3000個pods，并且每個pod大約有幾 KB的數據，意味著MB級的數據需要處理對于每個『LIST』操作。

已完成的工作和一些未來計劃

起初的性能可以滿足在100個節點的集群之上做任何測試都能足夠穩定的運行，包括很多小的修復和協調，如在apiserver增加文件描述符的限制和對etcd在不同請求之間重新使用tcp連接。

然而，構建一個穩定性能的測試只是完成了第一步，使我們的集群支持增加10倍的節點。正如這個工作的結果所展示的，我們已經盡全力消除未來的瓶頸，包括：

1. 重寫controllers，使其可以被觀察：之前他們是每隔幾秒重新列出指定類型的對象，這會對apiserver造成極大的負載。
2. 使用代碼生成器去生成轉換和深度復制的函數：盡管默認使用Go的反射功能非常方便，但它被證明效率非常的低，和生成代碼相比慢10倍左右。
3. 添加一個緩存給apiserver，避免從etcd多次讀取相同數據而造成的反序列化。
4. 減少更新狀態的頻率：顯示一個緩慢自然變化的狀態，只是在更新pod狀態時，節點狀態每10秒鐘更新一次才可以理解。
5. 在apiserver實現觀察功能而不是重定向請求給etcd：我們更希望避免多次觀察到相同的數據從etcd而來，因為，在很多情況下，它會被apiserver過濾掉。

進一步看，對于1000個節點的集群目標，建議實現的功能包括：

1. 將事件從etcd中移除：他們更像是系統日志，并不是系統狀態的一部分，也不是Kubernetes正確運行的關鍵點。
2. 使用json解析器：默認使用的Go語言解析器非常慢，因為它是基于反射實現的。
3. 重寫調度，使其更高效和滿足并發
4. apiserver和kubelets間溝通提升效率：特別是我們計劃在每次更新節點狀態時減小傳輸數據的大小。

這絕不是一個詳盡的清單。我們會不斷添加新的內容（或者刪除現有的內容），基于在運行現有擴展性測試和新的測試中注意到的瓶頸。如果有特別使用場景和方案你希望我們去解決，請把它們加進來！

• 我們會每周召開Kubernetes關于擴展討論的小組會議去討論問題和性能跟蹤和提高的計劃。
• 如果你有性能和擴展性的問題，可以通過Slack加入我們的討論：
  https://kubernetes.slack.com/messages/sig-scale
• 一般性問題可以加入我們Kubernetes社區討論：
  https://kubernetes.slack.com/m ... sers/
• 提交合入和提出問題，你可以在GitHub上完成。非常歡迎每個人貢獻你們的經驗或者PR來使Kubernetes變得更好。

**需要注意的是我們排除了API響應性參數中所有對『events』資源的操作，我們不提供任何保證對于它們，因為，這些不會影響Kubernetes去正確操作的能力（它們更像是系統日志）。*

原文鏈接： Kubernetes Performance Measurements and Roadmap （譯者：何煒）