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 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入 InfoQ 读者交流群）。