摘要：隨著發布，現在能支持個節點的集群即千萬請求秒，附帶對大多數操作尾部這段延遲降低。的千萬并發令人乍舌三個月后，將會再次帶來倍的提升。

隨著Kubernetes1.2v發布，K8S現在能支持1000個節點的集群（即1千萬請求／秒），附帶對大多數API操作（99%尾部這段）延遲降低80%。這意味著在最近的6個月內，K8S支持的容量增加了10倍同時還保證用戶使用感受——99%pod啟動時間少于3秒，大多數API操作99%延遲在幾十毫秒（唯一例外是LIST操作，對于很大的集群需要幾百毫秒）。Kubernetes 1.2v的千萬并發令人乍舌？三個月后，K8S 1.3v將會再次帶來10倍的提升。

kubernetes 1.2v千萬并發實測，請看視頻：

視頻在這里 請點擊

在這個視頻里，我們看到集群規模上升到1000個節點上到達10MQPS(即每秒1千萬請求)，還包括了滾動更新，沒有宕機時間和任何尾部延遲。這在互聯網上也足以列入前百強的表現。
接下來，我們來介紹一下K8S是如何做到這些的，以及我們未來在K8S擴容性上進一步提高的計劃。

我們對于K8S的擴容性做的基準是基于以下服務層面上的目標（ServiceLevel Objectives）:

API的相應：99%的API調用返回時間都小于1秒

Pod啟動時間：99%的pod和它們容器（pull好的鏡像）在5秒內啟動

只有這兩點同時滿足，我們才說K8S的擴容性到達了怎樣怎樣一個節點的數量。我們持續收集和報告這些測量數據來作為我們項目測試的框架，測試也相應的分成了兩個部分：API相應時間和pod啟動時間。

API響應

K8S為用戶提供了一些抽象概念來代表他們的應用，比如說，用冗余控制器（即RC, Replicaiton Controller）作為一群pod的抽象。把所有RC列出來或把一個給定的RC所包含的所有pods列出來，就是一個很常見的場景（usecase）。但從另外一方面來說，很少會有需要去把系統里的所有pods列出來，比如說3萬個pod（即比如1000個節點，每個節點有30個pod）意味著150MB的數據（即5KB／pod* 3萬pods）。這個測試使用冗余控制器。

對于這個測試來說（假設N是集群里的節點數量），我們做了：

創建大約3N個的不同數量的冗余控制器（5，30，250副本），這樣我們總共會有30N的副本。我們分步來進行它們的創建（即不是同時開始的），然后一直等到它們跑起來。

在每個冗余控制器上都進行一些操作（擴容，列出所有實例等），把這些操作也分步來做，來測試每個操作的延遲性。這個和一個真實的用戶會進行的常規集群操作很類似。

停止和刪除系統內的所有冗余控制器。

這些測試的結果，請看下面“Kubernetes 1.2參數”的數據。
在1.3版本中，我們計劃會進一步延伸這些測試，內容會包含創建服務、部署、DaemonSets和其他API對象。

Pod啟動時間端對端的延遲

用戶對K8S來跳用和啟動一個pod所需時間非常感興趣。這個不僅僅是初次創建pod，而且也包括當節點失敗的時候，冗余控制器需要多久來創建一個代替的pod。

對于這個測試來說（假設N是集群里的節點數量），我們做了：

創建一個多帶帶的冗余控制器，有30＊N的副本，等它們全部都跑起來。我們也跑高密度的測試，有100*N的副本，但集群內的節點數量少一些。

啟用一系列的單個pod的冗余控制器－沒200毫秒起一個。對于每一個，我們都測量“端到端啟動總時間”（后面會具體定義這個時間）

停止和刪除系統中所有冗余控制器和pods

端到端啟動總時間，我們的定義是指從用戶給API server 發送需要生成一個冗余控制器請求那刻開始，一直到pod的“running&ready”這個狀態返回給用戶，這個過程走表的時間。這意味著，“podstartup time”（pod啟動時間）包含了RC的創建，依次序的話即創建pod、調度器調度pod、Kubernetes建立intra-pod的網絡、啟動容器、等待pod對健康檢查成功回應，以及到最后pod把它的狀態返回給API server，API server再給用戶，這一整個過程的所需時間。
我們當然可以通過去掉等待的時間或者創建pod的時間來人為大大地縮短“pod startup time”（pod啟動時間），但我們還是秉持堅信一個更為廣義的定義來契合最為現實的場景，才能使廣大用戶理解他們對K8S性能的真實期待。

所以結果如何呢？我們再Google Compute Engine上跑了測試。對于1000個節點的集群，master使用了一個n1-standard-32的VM（32核，120GB內存）。

API響應

下面兩張圖表代表了 99% API調用的延遲在K8S 1.0版本和1.2版本之間的對比，基于100個節點的集群（柱狀越短，表現越好）

對于LIST的操作，我們多帶帶來呈現結果，因為這些操作的延遲要高很多。

我們也跑了1000個節點的集群的測試。

因為LIST操作要大的多，所以我們再一次把這些操作的測試結果多帶帶來呈現：所有的延遲，在兩個不同的集群尺寸下，都低于1秒。

pod啟動端到端延遲

關于“pod啟動時間延遲”的結果（即前面說到的“pod端到端延遲”的部分）顯示在下圖。為了有參考，我們把K8S1.0版本針對100個節點集群的結果也顯示在了圖里的第一部分。

由圖可見，K8S 1.2 在性能上顯著減少了100個節點集群尾部（即99%這段）延遲時間，現在在K8S可提供的最大集群尺寸范圍內可以提供很低的pod啟動延遲。跟6個月之前相比，K8S現在1000個節點的集群無論在API調用延遲和pod啟動延遲上都有了全方面的提高。

在API server層面上創建“read cache”(read緩存) 參見：點我

在Kubelet里引入pod生命周期事件發生器（即PLEG -Pod Lifecycle Event Generator）參見：點我

提高調度器的流量 參見：點我

一個更高效的JSON parser

當然，我們工作還遠未結束，我們會持續提高Kubernetes的性能，就像Google對內使用Borg那樣，把K8S的scale增加到無窮大。基于對底層測試和生產環境中對容器集群的使用場景，我們目前對1.3已經有了如下規劃：

目前的瓶頸依然還是API server，花費大量時間在給JSONobject進行排列。我們家化增加protocol buffer來為集群內的組件溝通以及在etcd內存儲JSON objects做可選路徑。用戶依然可以使用JSON來跟APIserver進行溝通，但由于大量的K8S的溝通是集群內（API server向節點、調度器向API server等）。我們期待使用在master上CPU和memory的消耗會有顯著降低。

Kubernetes使用標簽來標示成組的objects。比如，來找到哪些pods屬于一個給定的冗余控制器，會需要把所有在同一個namesapce下的并且還符合標簽選擇器的pod都掃一遍。因此對于做一個有效的標簽索引的增加可以充分利用已有的APIobject緩存，這樣能更快速的來查找并且匹配符合標簽選擇器的對象，速度會提高很多。

調度的決定來自于很多不同的因素，包括基于資源來分布pods，基于相同的選擇器來分步pods(比如同一個服務、冗余控制器、工作等)等等。這些計算，尤其是選擇器的分步，可能還是有改進空間的，參見：點我

再就是etcd 3.0的發布值得期待，其中在設計上就有Kubernetes應用場景的考慮，將會帶來性能上的提高和引入新功能。CoreOS已經在開展把Kubernetes引入etcd3.0版本的工作，參見：點我

對于K8S 1.3的期待不至于這個列表，可以預見的是，我們將會在K8S1.3看到一個類似從1.0到1.2一樣的飛躍。

在過去的六個月，我們見證了Kubernetes性能的極大飛躍，能夠跑1000個節點的集群，同時還具備和之前版本較小集群規模同樣出色的回應性。但我們對此遠遠不滿足，我們會把Kubernetes推到更強大，K8S1.3將會更大程度地提高系統的scale、性能和回應性，同時還會增加新的功能，使得K8S更好地來適應高需求的、基于容器集群的應用。