Kubernetes距管理1000个节点还有多远？

为了尽快解决复杂问题，企业一般选择增加服务器节点作为解决方案。在很多情况下，资源的额外增加总是能换来时间上的回报。然而，增加节点个数来减少计算时间就像增加火箭级数来提高速度（tyranny of the rocket equation）一样——这类问题都是存在瓶颈的。一旦超过一定的规模，再增加节点不仅不会加快计算速度，反而会拖慢计算的进度。为此，谷歌公司专门推出了开源容器集群管理系统——Kubernetes，以实现资源的合理、高效的使用。在1.0版本阶段，Kubernetes已经能够管理最多100个节点。但是，谷歌公司一直希望在2015年底实现Kubernetes支持节点数量的10倍增长。那么，该项目现在究竟进展如何，未来又会沿着怎样的路线进行下去呢？近日，Kubernetes项目的官方博客就该问题进行了说明。

根据之间上亿次实验，谷歌公司提出了两个性能度量指标——API响应灵敏度（API-responsiveness）和Pod启动时间。其中，API响应灵敏度指的是X%以上的API能够在Y秒内返回结果，而Pod启动时间要求Z%以上的pod能够在T秒内启动完毕。需要注意的是，pod启动时间中的镜像文件需要提前下载到本地机器，以去除网络带宽对性能的影响。

为了测量性能，谷歌公司还专门搭建了一套连续测试的框架。每隔2-3个小时，系统就从HEAD创建一个包含100个节点的全尺寸集群（每个节点运行30个pod），然后在其上运行大规模测试。其中，master采用GCE n1-standard-4的机器（4核、15GB内存），节点采用GCE n1-standard-1的机器（1核、3.75GB内存）。测试步骤如下：

1. 创建pod和replication controller来填充集群；
2. 通过添加/删除pod或replication controller等操作产生负载，然后记录相关性能参数；
3. 停止所有的pod和replication controller；
4. 整理性能参数，确定是否满足预期。

此外，为了测量pod启动延迟，每个pod只包含一个运行“gcr.io/google_containers/pause:go”镜像的容器。而且容器启动后，就开始一直睡眠。

性能测试结果分为两个部分——Pod启动时间和API响应灵敏度。对于包含10%、20%、50%和100%节点数集群系统，其pod启动时间T分别如下：

	10%-full	25%-full	50%-full	100%-full
Z=50	0.90s	1.08s	1.33s	1.94s
Z=90	1.29s	1.49s	1.72s	2.50s
Z=99	1.59s	1.86s	2.56s	4.32s

从上表可以看出，即使是在包含100个节点的全尺寸集群中，Pod启动时间也可以满足99%以上的pod在5秒内启动完毕。而对于大部分情况，pod启动只需要1-2秒的时间。

在API响应灵敏度方面，集群系统对于不同操作的响应延迟如下图所示。

可以看出，所有操作的响应延迟均在1秒以内。而且，对于大部分情况，响应延迟只需要0.1-0.3秒，远远领先于1秒的目标。因此，Kubernetes的性能已经完全能够保证包含100个节点的集群系统中99%以上的API在1秒内返回结果，同时99%以上的pod能够在5秒内启动完毕。

虽然这些测试结果仍然是在100个节点的情况下进行，这一结果却表明了Kubernetes的稳定性。作为走向1000个节点的第一步，Kubernetes团队在这一阶段进行了大量努力——重新编写了基于观察的控制器、利用代码生成器来生成转换和深度拷贝函数、向API服务器添加了缓冲来避免多个etcd读取相同数据时的反串行化、减少了状态更新的频率以及在API服务器是实现了观察窗口等。这些努力为未来打下了很好的基础。据透露，Kubernetes如果要支持1000个节点，仍然需要在以下方面进行改进：

• 把事件从etcd中挪出
• 使用更好的json解释器
• 重写调度器来提高效率和并行度
• 改善API服务器和Kubelet时间的通信效率

感谢郭蕾对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至[email protected]。也欢迎大家通过新浪微博（@InfoQ，@丁晓昀），微信（微信号：InfoQChina）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入InfoQ读者交流群）。