摘要：隨著發(fā)布，現(xiàn)在能支持個(gè)節(jié)點(diǎn)的集群即千萬(wàn)請(qǐng)求秒，附帶對(duì)大多數(shù)操作尾部這段延遲降低。的千萬(wàn)并發(fā)令人乍舌三個(gè)月后，將會(huì)再次帶來(lái)倍的提升。

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

kubernetes 1.2v千萬(wàn)并發(fā)實(shí)測(cè)，請(qǐng)看視頻：

視頻在這里 請(qǐng)點(diǎn)擊

在這個(gè)視頻里，我們看到集群規(guī)模上升到1000個(gè)節(jié)點(diǎn)上到達(dá)10MQPS(即每秒1千萬(wàn)請(qǐng)求)，還包括了滾動(dòng)更新，沒(méi)有宕機(jī)時(shí)間和任何尾部延遲。這在互聯(lián)網(wǎng)上也足以列入前百?gòu)?qiáng)的表現(xiàn)。
接下來(lái)，我們來(lái)介紹一下K8S是如何做到這些的，以及我們未來(lái)在K8S擴(kuò)容性上進(jìn)一步提高的計(jì)劃。

我們對(duì)于K8S的擴(kuò)容性做的基準(zhǔn)是基于以下服務(wù)層面上的目標(biāo)（ServiceLevel Objectives）:

API的相應(yīng)：99%的API調(diào)用返回時(shí)間都小于1秒

Pod啟動(dòng)時(shí)間：99%的pod和它們?nèi)萜鳎╬ull好的鏡像）在5秒內(nèi)啟動(dòng)

只有這兩點(diǎn)同時(shí)滿(mǎn)足，我們才說(shuō)K8S的擴(kuò)容性到達(dá)了怎樣怎樣一個(gè)節(jié)點(diǎn)的數(shù)量。我們持續(xù)收集和報(bào)告這些測(cè)量數(shù)據(jù)來(lái)作為我們項(xiàng)目測(cè)試的框架，測(cè)試也相應(yīng)的分成了兩個(gè)部分：API相應(yīng)時(shí)間和pod啟動(dòng)時(shí)間。

API響應(yīng)

K8S為用戶(hù)提供了一些抽象概念來(lái)代表他們的應(yīng)用，比如說(shuō)，用冗余控制器（即RC, Replicaiton Controller）作為一群pod的抽象。把所有RC列出來(lái)或把一個(gè)給定的RC所包含的所有pods列出來(lái)，就是一個(gè)很常見(jiàn)的場(chǎng)景（usecase）。但從另外一方面來(lái)說(shuō)，很少會(huì)有需要去把系統(tǒng)里的所有pods列出來(lái)，比如說(shuō)3萬(wàn)個(gè)pod（即比如1000個(gè)節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)有30個(gè)pod）意味著150MB的數(shù)據(jù)（即5KB／pod* 3萬(wàn)pods）。這個(gè)測(cè)試使用冗余控制器。

對(duì)于這個(gè)測(cè)試來(lái)說(shuō)（假設(shè)N是集群里的節(jié)點(diǎn)數(shù)量），我們做了：

創(chuàng)建大約3N個(gè)的不同數(shù)量的冗余控制器（5，30，250副本），這樣我們總共會(huì)有30N的副本。我們分步來(lái)進(jìn)行它們的創(chuàng)建（即不是同時(shí)開(kāi)始的），然后一直等到它們跑起來(lái)。

在每個(gè)冗余控制器上都進(jìn)行一些操作（擴(kuò)容，列出所有實(shí)例等），把這些操作也分步來(lái)做，來(lái)測(cè)試每個(gè)操作的延遲性。這個(gè)和一個(gè)真實(shí)的用戶(hù)會(huì)進(jìn)行的常規(guī)集群操作很類(lèi)似。

停止和刪除系統(tǒng)內(nèi)的所有冗余控制器。

這些測(cè)試的結(jié)果，請(qǐng)看下面“Kubernetes 1.2參數(shù)”的數(shù)據(jù)。
在1.3版本中，我們計(jì)劃會(huì)進(jìn)一步延伸這些測(cè)試，內(nèi)容會(huì)包含創(chuàng)建服務(wù)、部署、DaemonSets和其他API對(duì)象。

Pod啟動(dòng)時(shí)間端對(duì)端的延遲

用戶(hù)對(duì)K8S來(lái)跳用和啟動(dòng)一個(gè)pod所需時(shí)間非常感興趣。這個(gè)不僅僅是初次創(chuàng)建pod，而且也包括當(dāng)節(jié)點(diǎn)失敗的時(shí)候，冗余控制器需要多久來(lái)創(chuàng)建一個(gè)代替的pod。

對(duì)于這個(gè)測(cè)試來(lái)說(shuō)（假設(shè)N是集群里的節(jié)點(diǎn)數(shù)量），我們做了：

創(chuàng)建一個(gè)多帶帶的冗余控制器，有30＊N的副本，等它們?nèi)慷寂芷饋?lái)。我們也跑高密度的測(cè)試，有100*N的副本，但集群內(nèi)的節(jié)點(diǎn)數(shù)量少一些。

啟用一系列的單個(gè)pod的冗余控制器－沒(méi)200毫秒起一個(gè)。對(duì)于每一個(gè)，我們都測(cè)量“端到端啟動(dòng)總時(shí)間”（后面會(huì)具體定義這個(gè)時(shí)間）

停止和刪除系統(tǒng)中所有冗余控制器和pods

端到端啟動(dòng)總時(shí)間，我們的定義是指從用戶(hù)給API server 發(fā)送需要生成一個(gè)冗余控制器請(qǐng)求那刻開(kāi)始，一直到pod的“running&ready”這個(gè)狀態(tài)返回給用戶(hù)，這個(gè)過(guò)程走表的時(shí)間。這意味著，“podstartup time”（pod啟動(dòng)時(shí)間）包含了RC的創(chuàng)建，依次序的話(huà)即創(chuàng)建pod、調(diào)度器調(diào)度pod、Kubernetes建立intra-pod的網(wǎng)絡(luò)、啟動(dòng)容器、等待pod對(duì)健康檢查成功回應(yīng)，以及到最后pod把它的狀態(tài)返回給API server，API server再給用戶(hù)，這一整個(gè)過(guò)程的所需時(shí)間。
我們當(dāng)然可以通過(guò)去掉等待的時(shí)間或者創(chuàng)建pod的時(shí)間來(lái)人為大大地縮短“pod startup time”（pod啟動(dòng)時(shí)間），但我們還是秉持堅(jiān)信一個(gè)更為廣義的定義來(lái)契合最為現(xiàn)實(shí)的場(chǎng)景，才能使廣大用戶(hù)理解他們對(duì)K8S性能的真實(shí)期待。

所以結(jié)果如何呢？我們?cè)貵oogle Compute Engine上跑了測(cè)試。對(duì)于1000個(gè)節(jié)點(diǎn)的集群，master使用了一個(gè)n1-standard-32的VM（32核，120GB內(nèi)存）。

API響應(yīng)

下面兩張圖表代表了 99% API調(diào)用的延遲在K8S 1.0版本和1.2版本之間的對(duì)比，基于100個(gè)節(jié)點(diǎn)的集群（柱狀越短，表現(xiàn)越好）

對(duì)于LIST的操作，我們多帶帶來(lái)呈現(xiàn)結(jié)果，因?yàn)檫@些操作的延遲要高很多。

我們也跑了1000個(gè)節(jié)點(diǎn)的集群的測(cè)試。

因?yàn)長(zhǎng)IST操作要大的多，所以我們?cè)僖淮伟堰@些操作的測(cè)試結(jié)果多帶帶來(lái)呈現(xiàn)：所有的延遲，在兩個(gè)不同的集群尺寸下，都低于1秒。

pod啟動(dòng)端到端延遲

關(guān)于“pod啟動(dòng)時(shí)間延遲”的結(jié)果（即前面說(shuō)到的“pod端到端延遲”的部分）顯示在下圖。為了有參考，我們把K8S1.0版本針對(duì)100個(gè)節(jié)點(diǎn)集群的結(jié)果也顯示在了圖里的第一部分。

由圖可見(jiàn)，K8S 1.2 在性能上顯著減少了100個(gè)節(jié)點(diǎn)集群尾部（即99%這段）延遲時(shí)間，現(xiàn)在在K8S可提供的最大集群尺寸范圍內(nèi)可以提供很低的pod啟動(dòng)延遲。跟6個(gè)月之前相比，K8S現(xiàn)在1000個(gè)節(jié)點(diǎn)的集群無(wú)論在API調(diào)用延遲和pod啟動(dòng)延遲上都有了全方面的提高。

在API server層面上創(chuàng)建“read cache”(read緩存) 參見(jiàn)：點(diǎn)我

在Kubelet里引入pod生命周期事件發(fā)生器（即PLEG -Pod Lifecycle Event Generator）參見(jiàn)：點(diǎn)我

提高調(diào)度器的流量 參見(jiàn)：點(diǎn)我

一個(gè)更高效的JSON parser

當(dāng)然，我們工作還遠(yuǎn)未結(jié)束，我們會(huì)持續(xù)提高Kubernetes的性能，就像Google對(duì)內(nèi)使用Borg那樣，把K8S的scale增加到無(wú)窮大?；趯?duì)底層測(cè)試和生產(chǎn)環(huán)境中對(duì)容器集群的使用場(chǎng)景，我們目前對(duì)1.3已經(jīng)有了如下規(guī)劃：

目前的瓶頸依然還是API server，花費(fèi)大量時(shí)間在給JSONobject進(jìn)行排列。我們家化增加protocol buffer來(lái)為集群內(nèi)的組件溝通以及在etcd內(nèi)存儲(chǔ)JSON objects做可選路徑。用戶(hù)依然可以使用JSON來(lái)跟APIserver進(jìn)行溝通，但由于大量的K8S的溝通是集群內(nèi)（API server向節(jié)點(diǎn)、調(diào)度器向API server等）。我們期待使用在master上CPU和memory的消耗會(huì)有顯著降低。

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

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

再就是etcd 3.0的發(fā)布值得期待，其中在設(shè)計(jì)上就有Kubernetes應(yīng)用場(chǎng)景的考慮，將會(huì)帶來(lái)性能上的提高和引入新功能。CoreOS已經(jīng)在開(kāi)展把Kubernetes引入etcd3.0版本的工作，參見(jiàn)：點(diǎn)我

對(duì)于K8S 1.3的期待不至于這個(gè)列表，可以預(yù)見(jiàn)的是，我們將會(huì)在K8S1.3看到一個(gè)類(lèi)似從1.0到1.2一樣的飛躍。

在過(guò)去的六個(gè)月，我們見(jiàn)證了Kubernetes性能的極大飛躍，能夠跑1000個(gè)節(jié)點(diǎn)的集群，同時(shí)還具備和之前版本較小集群規(guī)模同樣出色的回應(yīng)性。但我們對(duì)此遠(yuǎn)遠(yuǎn)不滿(mǎn)足，我們會(huì)把Kubernetes推到更強(qiáng)大，K8S1.3將會(huì)更大程度地提高系統(tǒng)的scale、性能和回應(yīng)性，同時(shí)還會(huì)增加新的功能，使得K8S更好地來(lái)適應(yīng)高需求的、基于容器集群的應(yīng)用。