本文是CoreOS近期对Kubernetes扩容性的一些针对性试验、检测和研究，分析并且得出了对Kubernetes集群部署和pod吞吐量等Kubernetes集群性能问题、扩容性问题上一系列的尝试和见解。该文章回顾了从硬件到软件层面采用缩小范围以及使用Kubernetes提供的端对端API性能指标和使用benchmarking作为基准工具等手段进行对建立不同规模集群过程中的pod吞吐量测试，从而发现Kubernetes集群调度器性能的潜在瓶颈和潜在解决方案。
扩容性对任何一个分布式系统的成功而言都是一个重要的因素。在CoreOS，我们非常喜欢Kubernetes，希望能够通过对上游的贡献来推进这个项目。去年11月，我们组建了一个团队，专门研究Kubernetes的扩容性。我们设定了一个目标来检测和理解Kubernetes集群的性能，从而获取集群在工作量很大的情况下的表现性能，来获取Kubernetes集群的性能问题大概在什么地方。
很快我们就开展了这方面的工作，我们发现了一系列的瓶颈。通过解决这些瓶颈，我们把Kubernetes调度基准在1千个节点上调度3万个pod的时间从8780秒降到587秒。在这篇文章里，分享了我们是如何获得这个超过了十倍的性能提升，并且希望能够抛砖引玉，让社区可以进一步提升Kubernetes的扩容性。
Kubernetes架构概览
为了理解和提高Kubernetes的性能，我们首先需要建立一个适于当前能力的基线。一个Kubernetes集群是由一整套控制管理集群操作的API节点来组成的，API节点跑在工作节点上，应用的pods也同样跑在这些节点上。我们最初把目光聚集在控制层部件，因为它们参与了集群层面的每一个调度操作，这是我们理解性能最有可能提升的地方。Kubernetes的构架参见下图。
对Kubemark的试验
Kubernetes社区最近推出了Kubemark，用来测试控制层部件的性能。Kubemark模拟了工作节点，可以在一个单独的CPU内核上模拟10个真实节点，让我们以最低的复杂度和消耗来模拟大型集群。
我们对Kubemark的第一个使用是做了一个密度测试，来测量在每一个节点上调度30个pod，Kubemark所需要的时间。对一个100个节点的集群来说，有3千个pod需要调度和跑起来；对于1000个节点的集群而言，那就有3万个pod。这些测试结果显示了在不同时期的pod数量。我们所有的测试，集群都是连接在一个etcd集群上，etcd跑在一个单独机器上。
我们以一个拥有100节点的集群测试来开始我们的调查，它在150秒内完成了调度3千个节点的任务。pod的吞吐量在20个pod/秒。为了更好的理解这个日志，我们写了一个plot工具来画图。
下面这个图显示了由 replication controller建立但并非调度的pod，显示了它们一旦被调度到集群的机器里跑起来的时候。
我们很快注意到这个图显示了一个pod创建的线性情况, 在20个pod／秒，看上去很低，说明存在一个潜在的可以提高的瓶颈和目标。我们就从这里开始性能的旅程。
奔向更好吞吐量的旅程
我们脑海中想到的第一件事情是也许硬件资源吃紧了。如果是这样的话，我们可以简单地通过增加资源来提高调度的性能。我们又跑了测试，监控CPU、内存、IO使用率到顶的情况。结果看上去如下：
从我们所观察到的来看，没有任何物理资源是被完全使用的。这说明问题出在软件上。
在一个类似Kubernetes这样庞大的代码库中去发现瓶颈，犹如大海捞针。我们需要一步步来缩小范围。幸运的是，Kubernetes提供了大多数端对端API调用的性能指标（被Prometheus这个开源项目所收集）。我们第一步就是在这里面寻找。我们又跑了测试，监控了调度器的指标。结果如下：