本文是CoreOS近期對(duì)Kubernetes擴(kuò)容性的一些針對(duì)性試驗(yàn)、檢測(cè)和研究，分析并且得出了對(duì)Kubernetes集群部署和pod吞吐量等Kubernetes集群性能問(wèn)題、擴(kuò)容性問(wèn)題上一系列的嘗試和見(jiàn)解。該文章回顧了從硬件到軟件層面采用縮小范圍以及使用Kubernetes提供的端對(duì)端API性能指標(biāo)和使用benchmarking作為基準(zhǔn)工具等手段進(jìn)行對(duì)建立不同規(guī)模集群過(guò)程中的pod吞吐量測(cè)試，從而發(fā)現(xiàn)Kubernetes集群調(diào)度器性能的潛在瓶頸和潛在解決方案。
擴(kuò)容性對(duì)任何一個(gè)分布式系統(tǒng)的成功而言都是一個(gè)重要的因素。在CoreOS，我們非常喜歡Kubernetes，希望能夠通過(guò)對(duì)上游的貢獻(xiàn)來(lái)推進(jìn)這個(gè)項(xiàng)目。去年11月，我們組建了一個(gè)團(tuán)隊(duì)，專門(mén)研究Kubernetes的擴(kuò)容性。我們?cè)O(shè)定了一個(gè)目標(biāo)來(lái)檢測(cè)和理解Kubernetes集群的性能，從而獲取集群在工作量很大的情況下的表現(xiàn)性能，來(lái)獲取Kubernetes集群的性能問(wèn)題大概在什么地方。
很快我們就開(kāi)展了這方面的工作，我們發(fā)現(xiàn)了一系列的瓶頸。通過(guò)解決這些瓶頸，我們把Kubernetes調(diào)度基準(zhǔn)在1千個(gè)節(jié)點(diǎn)上調(diào)度3萬(wàn)個(gè)pod的時(shí)間從8780秒降到587秒。在這篇文章里，分享了我們是如何獲得這個(gè)超過(guò)了十倍的性能提升，并且希望能夠拋磚引玉，讓社區(qū)可以進(jìn)一步提升Kubernetes的擴(kuò)容性。
Kubernetes架構(gòu)概覽
為了理解和提高Kubernetes的性能，我們首先需要建立一個(gè)適于當(dāng)前能力的基線。一個(gè)Kubernetes集群是由一整套控制管理集群操作的API節(jié)點(diǎn)來(lái)組成的，API節(jié)點(diǎn)跑在工作節(jié)點(diǎn)上，應(yīng)用的pods也同樣跑在這些節(jié)點(diǎn)上。我們最初把目光聚集在控制層部件，因?yàn)樗鼈儏⑴c了集群層面的每一個(gè)調(diào)度操作，這是我們理解性能最有可能提升的地方。Kubernetes的構(gòu)架參見(jiàn)下圖。
對(duì)Kubemark的試驗(yàn)
Kubernetes社區(qū)最近推出了Kubemark，用來(lái)測(cè)試控制層部件的性能。Kubemark模擬了工作節(jié)點(diǎn)，可以在一個(gè)單獨(dú)的CPU內(nèi)核上模擬10個(gè)真實(shí)節(jié)點(diǎn)，讓我們以最低的復(fù)雜度和消耗來(lái)模擬大型集群。
我們對(duì)Kubemark的第一個(gè)使用是做了一個(gè)密度測(cè)試，來(lái)測(cè)量在每一個(gè)節(jié)點(diǎn)上調(diào)度30個(gè)pod，Kubemark所需要的時(shí)間。對(duì)一個(gè)100個(gè)節(jié)點(diǎn)的集群來(lái)說(shuō)，有3千個(gè)pod需要調(diào)度和跑起來(lái)；對(duì)于1000個(gè)節(jié)點(diǎn)的集群而言，那就有3萬(wàn)個(gè)pod。這些測(cè)試結(jié)果顯示了在不同時(shí)期的pod數(shù)量。我們所有的測(cè)試，集群都是連接在一個(gè)etcd集群上，etcd跑在一個(gè)單獨(dú)機(jī)器上。
我們以一個(gè)擁有100節(jié)點(diǎn)的集群測(cè)試來(lái)開(kāi)始我們的調(diào)查，它在150秒內(nèi)完成了調(diào)度3千個(gè)節(jié)點(diǎn)的任務(wù)。pod的吞吐量在20個(gè)pod/秒。為了更好的理解這個(gè)日志，我們寫(xiě)了一個(gè)plot工具來(lái)畫(huà)圖。
下面這個(gè)圖顯示了由 replication controller建立但并非調(diào)度的pod，顯示了它們一旦被調(diào)度到集群的機(jī)器里跑起來(lái)的時(shí)候。
我們很快注意到這個(gè)圖顯示了一個(gè)pod創(chuàng)建的線性情況, 在20個(gè)pod／秒，看上去很低，說(shuō)明存在一個(gè)潛在的可以提高的瓶頸和目標(biāo)。我們就從這里開(kāi)始性能的旅程。
奔向更好吞吐量的旅程
我們腦海中想到的第一件事情是也許硬件資源吃緊了。如果是這樣的話，我們可以簡(jiǎn)單地通過(guò)增加資源來(lái)提高調(diào)度的性能。我們又跑了測(cè)試，監(jiān)控CPU、內(nèi)存、IO使用率到頂?shù)那闆r。結(jié)果看上去如下：
從我們所觀察到的來(lái)看，沒(méi)有任何物理資源是被完全使用的。這說(shuō)明問(wèn)題出在軟件上。
在一個(gè)類似Kubernetes這樣龐大的代碼庫(kù)中去發(fā)現(xiàn)瓶頸，猶如大海撈針。我們需要一步步來(lái)縮小范圍。幸運(yùn)的是，Kubernetes提供了大多數(shù)端對(duì)端API調(diào)用的性能指標(biāo)（被Prometheus這個(gè)開(kāi)源項(xiàng)目所收集）。我們第一步就是在這里面尋找。我們又跑了測(cè)試，監(jiān)控了調(diào)度器的指標(biāo)。結(jié)果如下：