通過使用這些變化，我們獲得了難以置信的新能提升——調(diào)度吞度量達(dá)到51pod/秒。我們又一次跑了調(diào)度器的基準(zhǔn)為1千個節(jié)點集群上調(diào)度3萬個pod，拿它和之前的結(jié)果相比較，請看下圖：
請注意這個過程比跑Kubemark時間更長，有可能是垃圾回收導(dǎo)致的。我們把所有東西放在同一個程序里，Kubemark在不同的進(jìn)程里來跑調(diào)度器、API服務(wù)器和controller管理器。但這個區(qū)別不影響比較的結(jié)果，假設(shè)這樣是有可比性的。
現(xiàn)狀和未來的步驟
通過我們的優(yōu)化，我們重新跑了Kubemark“1千個節(jié)點／3萬個pod”測試。結(jié)果如下圖：
現(xiàn)在，平均pod吞吐量為16.3pod/秒，之前數(shù)據(jù)為5.72pod/秒。首先，我們看到了吞吐量的提高。第二，這個數(shù)字仍然比我們調(diào)度器基準(zhǔn)的要低。我們確信在這點上，調(diào)度器本身不太可能是瓶頸。有很多其他因素，比如遠(yuǎn)程調(diào)用延遲、API服務(wù)器中的垃圾回收等等。這可能是一個未來性能提升的下一個探索方向。
擴(kuò)容Kubernetes
在這篇博文中，我們討論了我們是如何分析類似于性能指標(biāo)和CPU歸檔的實驗結(jié)果來確定性能瓶頸和提高調(diào)度器的。
為了更好的理解調(diào)度器，我們提供了一個基準(zhǔn)工具，我們用它來驗證我們的性能提升。到我們目前的工作位置，我們把1千個節(jié)點上調(diào)度3萬個pod的時間從8780秒降低到了587秒，給Kubernetes發(fā)了4個PR。
盡管在這里描述的技術(shù)很簡單，把我們的想法過程分享給大家會幫助其他人通過把調(diào)查研究切分成能夠處理的一塊一塊，從而來debug復(fù)雜的分布式系統(tǒng)。
這里重要的是以下幾點：
性能指標(biāo)提供了一個便利和非常亟需的觀察系統(tǒng)的視野 使用基準(zhǔn)是一個圖解性能和發(fā)現(xiàn)任何潛在問題的有效方式 畫圖是一種在一段時間后觀察系統(tǒng)比較好的方法
譯者：才云科技聯(lián)合創(chuàng)始人&COO 韓佳瑤
原文鏈接：https://coreos.com/blog/improving-kubernetes-scheduler-performance.html#rd?sukey=014c68f407f2d3e1b70054f7d5d62ff9043c7ae9852e675c41646ed644e2a15b91af49f6cb635553efeb3f47d78e0371