【AICon】探索RAG 技术在实际应用中遇到的挑战及应对策略!AICon精华内容已上线73%>>> 了解详情
写点什么

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

  • 2015-09-23
  • 本文字数:1575 字

    阅读完需:约 5 分钟

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

2015-09-23 19:003034
用户头像

发布了 268 篇内容, 共 117.7 次阅读, 收获喜欢 24 次。

关注

评论

发布
暂无评论
发现更多内容

卓越工程之开发过程管理

agnostic

卓越工程

5.5G,运营商能接受吗?

脑极体

5.5G

新一代分布式任务调度框架

程序员大彬

Java 面试

架构师日记-如何写的一手好代码

京东科技开发者

代码质量 代码 京东云 企业号 4 月 PK 榜

一个神奇的需求:doc批量转docx,1行Python代码实现

程序员晚枫

Python word 自动化办公

不敲一行代码,用ChatGPT开发App

FN0

移动开发 ChatGPT

2023年最新大厂金三银四必问1200道Java面试题,面面俱到!太全了

采菊东篱下

Java

限失真信源编码

timerring

限失真信源编码

MySQL 索引常见问题汇总,一次性梳理

做梦都在改BUG

Java MySQL 数据库 索引

阿里CTO最新分享神仙级“多线程手册”全套笔记,涵盖了多线程相关所有知识点

开心学Java

Java 线程 多线程 阿里

涨薪跳板! 2023阿里突击版Java面试宝典

程序知音

Java 编程语言 java面试 java架构 后端技术

Django笔记一之运行系统、创建视图并访问

Hunter熊

django

业务防资损,质量保障的第一要务!

老张

业务价值 交付质量 防资损

肝完阿里最新Java并发编程全优笔记,我成功晋升公司架构组

程序员小毕

Java 源码 程序员 面试 并发编程

好用的图片管理器:ImageRanger Pro Edition激活版

真大的脸盆

图片管理器 图片管理 管理图片 图片处理工具

Meetup 回顾|Data Infra 研究社第十期(含资料发布)

Databend

单机最快的队列Disruptor解析和使用

小小怪下士

Alfred 教程:如何在 Mac 之间同步 Alfred 设置?

Rose

Alfred 5 苹果效率工具 Alfred 教程 Mac 之间同步 Alfred

阿里内部最新发布的并发图册+JDK源码速成笔记,终于解脱束缚了

开心学Java

Java jdk 高并发

设计模式之美--经常被用错的KISS、YAGNI原则

GalaxyCreater

设计模式

JSF预热功能的实践与探索

京东科技开发者

京东云 jsf 企业号 4 月 PK 榜

火了!北大学霸爆肝3个月的算法小抄完整笔记,GitHub疯狂转发

做梦都在改BUG

Java 数据结构 算法

Spring Boot+Nacos+gRPC,一个区别于 OpenFeign 的微服务通信方案!

江南一点雨

gRPC nacos springboot

Service进阶

攻城狮Wayne

service intentservice 轮询

【算法数据结构专题】「延时队列算法」史上手把手教你针对层级时间轮(TimingWheel)实现延时队列的开发实战落地(上)

洛神灬殇

4月月更 时间轮(TimeWheel) 算法指南 技术调整

阿里大佬力荐K8s项目实战笔记!图文并茂带你深度解析Kubernetes

做梦都在改BUG

Java Kubernetes k8s

深度学习基础入门篇[一]:神经元简介、单层多层感知机、距离计算方法式、相似度函数

汀丶人工智能

人工智能 机器学习 深度学习 多层感知机

负载均衡算法的实现

王玉川

c++ 负载均衡 高可用 高并发 一致性哈希

云计算时代前端如何保证开源代码的安全性

京东科技开发者

前端 安全 京东云 京东科技 企业号 4 月 PK 榜

深入理解MySQL索引底层数据结构

京东科技开发者

MySQL 京东云 京东技术 企业号 4 月 PK 榜

首届“兴智杯”产业赛收官,文心大模型助推产业创新

飞桨PaddlePaddle

人工智能 深度学习 飞桨 产业赋能

Kubernetes距管理1000个节点还有多远?_语言 & 开发_张天雷_InfoQ精选文章