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

来源:InfoQ 作者: 张天雷
  

为了尽快解决复杂问题,企业一般选择增加服务器节点作为解决方案。在很多情况下,资源的额外增加总是能换来时间上的回报。然而,增加节点个数来减少计算时间就像增加火箭级数来提高速度(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时间的通信效率

时间:2015-09-24 09:32 来源:InfoQ 作者: 张天雷 原文链接

好文,顶一下
(0)
0%
文章真差,踩一下
(0)
0%
------分隔线----------------------------


把开源带在你的身边-精美linux小纪念品
无觅相关文章插件,快速提升流量