通过使用这些变化，我们获得了难以置信的新能提升——调度吞度量达到51pod/秒。我们又一次跑了调度器的基准为1千个节点集群上调度3万个pod，拿它和之前的结果相比较，请看下图：
请注意这个过程比跑Kubemark时间更长，有可能是垃圾回收导致的。我们把所有东西放在同一个程序里，Kubemark在不同的进程里来跑调度器、API服务器和controller管理器。但这个区别不影响比较的结果，假设这样是有可比性的。
现状和未来的步骤
通过我们的优化，我们重新跑了Kubemark“1千个节点／3万个pod”测试。结果如下图：
现在，平均pod吞吐量为16.3pod/秒，之前数据为5.72pod/秒。首先，我们看到了吞吐量的提高。第二，这个数字仍然比我们调度器基准的要低。我们确信在这点上，调度器本身不太可能是瓶颈。有很多其他因素，比如远程调用延迟、API服务器中的垃圾回收等等。这可能是一个未来性能提升的下一个探索方向。
扩容Kubernetes
在这篇博文中，我们讨论了我们是如何分析类似于性能指标和CPU归档的实验结果来确定性能瓶颈和提高调度器的。
为了更好的理解调度器，我们提供了一个基准工具，我们用它来验证我们的性能提升。到我们目前的工作位置，我们把1千个节点上调度3万个pod的时间从8780秒降低到了587秒，给Kubernetes发了4个PR。
尽管在这里描述的技术很简单，把我们的想法过程分享给大家会帮助其他人通过把调查研究切分成能够处理的一块一块，从而来debug复杂的分布式系统。
这里重要的是以下几点：
性能指标提供了一个便利和非常亟需的观察系统的视野 使用基准是一个图解性能和发现任何潜在问题的有效方式 画图是一种在一段时间后观察系统比较好的方法
译者：才云科技联合创始人&COO 韩佳瑶
原文链接：https://coreos.com/blog/improving-kubernetes-scheduler-performance.html#rd?sukey=014c68f407f2d3e1b70054f7d5d62ff9043c7ae9852e675c41646ed644e2a15b91af49f6cb635553efeb3f47d78e0371