安徽龙山建设有限公司网站,企业网站系统设计与实现,上海到北京多远,商标设计网免费简介#xff1a; 脱胎于阿里巴巴内部#xff0c;经过多年双 11 打磨#xff0c;每年为公司节省数十亿的混部系统 Koordinator 今天宣布正式开源。通过开源#xff0c;我们希望将更好的混部能力、调度能力开放到整个行业#xff0c;帮助企业客户改进云原生工作负载运行的效…简介 脱胎于阿里巴巴内部经过多年双 11 打磨每年为公司节省数十亿的混部系统 Koordinator 今天宣布正式开源。通过开源我们希望将更好的混部能力、调度能力开放到整个行业帮助企业客户改进云原生工作负载运行的效率、稳定性和计算成本。 作者 | 逐灵 来源 | 阿里技术公众号
脱胎于阿里巴巴内部经过多年双 11 打磨每年为公司节省数十亿的混部系统 Koordinator 今天宣布正式开源。通过开源我们希望将更好的混部能力、调度能力开放到整个行业帮助企业客户改进云原生工作负载运行的效率、稳定性和计算成本。混部是什么
业界很多互联网公司或多或少都有布局将不同特征类型工作负载协同调度的技术方向充分利用负载之间的消峰填谷效应让工作负载以更稳定、更高效、更低成本的方式去使用资源。这样的一套系统或机制也就是业界时常提及的 “混部”概念。
阿里巴巴的混部
阿里巴巴在 2011 年开始探索容器技术并在 2016 年启动混部技术研发至今经过了多轮技术架构升级最终演进到今天的云原生混部系统架构实现了全业务规模超千万核的云原生混部混部天平均 CPU 利用率超 50%帮助阿里巴巴节省了大量的资源成本。
混部是在互联网企业内部重金打造的成本控制内核凝聚了众多的业务抽象和资源管理的思考优化经验因此混部通常都需要数年的打磨实践才能逐渐稳定并产生生产价值。是不是每家企业都需要很高的门槛才能使用混部都需要大量的投入才能产生价值那让我们的Koordinator来尝试给出回答。
Koordinator 正是基于内部超大规模混部生产实践经验而来旨在为用户打造云原生场景下接入成本最低、混部效率最佳的解决方案帮助用户企业实现云原生后持续的红利释放。
一 Koordinator 是什么
Koordinator: 取自 coordinatorK for Kubernetes发音相同。语意上契合项目要解决的问题即协调编排 kubernetes 集群中不同类型的工作负载使得他们以最优的布局、最佳的姿态在一个集群、一个节点上运行。
谷歌内部有一个调度系统名叫 Borg是最早做容器混部的系统在其论文公开发表之前在行业上一直是非常神秘的存在。云原生容器调度编排系统 Kubernetes 正是受 Borg 设计思想启发由 Borg 系统的设计者结合云时代应用编排的需求重新设计而来。Kubernetes 良好的扩展性使其能适应多样的工作负载帮助用户很好的解决工作负载日常运维效率。
Koordinator 是完全基于 Kubernetes 标准能力扩展而来致力于解决多样工作负载混部在一个集群、节点场景下的调度、运行时性能以及稳定性挑战。项目包含了混合工作负载编排的一套完整解决方案包括精细化资源调度、任务调度、差异化 SLO 三大块。通过这样一套解决方案实现
帮助企业用户更多工作负载接入 kubernetes特别是大数据、任务处理相关的工作负载提高其运行效率和稳定性通过开源技术标准帮助企业用户在云上、云下实现一致的技术架构提升运维效率帮助企业用户合理利用云资源在云上实现可持续发展
二 Koordinator 有什么优势
混部需要一套完整、自闭环的调度回路但在企业应用混部的过程中将要面临的两大挑战是
应用如何接入到混部平台应用如何在平台上能够运行稳定、高效
Koordinator 吸取了阿里巴巴内部多年的生产实践经验教训针对这两大挑战针对性的设计了解决方案旨在帮助企业真正意义上的用上混部用好 Kubernetes而不是秀技术秀肌肉。
Koordinator 1.0 的整体架构如下图所示为了用户提供了完整的混部工作负载编排、混部资源调度、混部资源隔离及性能调优解决方案帮助用户提高延迟敏感服务的运行性能挖掘空闲节点资源并分配给真正有需要的计算任务从而提高全局的资源利用效率。 1 超大规模生产实践经验锤炼
2021 双 11 之后阿里对外宣布了“首次统一调度系统规模化落地全面支撑阿里巴巴双 11 全业务”
作为阿里巴巴的核心项目阿里云容器团队和大数据团队联合阿里巴巴资源效能团队、蚂蚁容器编排团队历时一年多研发和技术攻坚实现了从“混部技术”到今天“统一调度技术”的全面升级。
今天统一调度已实现阿里巴巴电商、搜推广、MaxCompute 大数据的调度全面统一实现了 pod 调度和 task 高性能调度的统一实现了完整的资源视图统一和调度协同实现了多种复杂业务形态的混部和利用率提升全面支撑了全球数十个数据中心、数百万容器、数千万核的大规模资源调度。
作为云原生混部的践行者阿里巴巴是真刀真枪的在生产环境中推进混部技术理念并在去年双 11 完成了超过千万核的混部规模通过混部技术帮助阿里巴巴双 11 节约超过 50% 的大促资源成本在大促快上快下链路上提速 100%助力大促实现丝滑的用户体验。 回头去看阿里巴巴坚定的推进混部技术主要是考虑到以下方面带来的问题
利用率不均衡在非混部时代几大资源池之间的资源利用率不均衡大数据资源池利用率极高长期缺乏算力而电商资源池日常利用率比较低空闲了大量的计算资源但出于灾备设计又不能直接下掉机器提高在线密度。混部的初衷是让全局资源调度更合理在日常态通过混部将大数据的任务调度到电商资源池中充分利用这部分空闲的资源。大促备战效率低在大促时为了减少大促资源采购希望在大促时能够借用大数据资源池部署电商任务支撑流量洪峰同时。在非混部时代这样的弹性资源借用只能通过腾挪机器的方式推进大促支持的效率较低很难大规模实施。
正是在双 11 这样的峰值场景驱动之下阿里的混部调度技术持续演进积累了大量的生产实践经验到今天已经是第三代即云原生全业务混部系统。这样一套基于云原生理念的混部技术解决方案脱胎于阿里巴巴希望通过开源社区辐射到整个行业帮助企业在云原生容器调度方向上加速快跑。
2 聚焦混部技术支持丰富的场景
混部是一套针对延迟敏感服务的精细化编排大数据计算工作负载混合部署的资源调度解决方案核心技术在于
精细的资源编排以满足性能及长尾时延的要求关键点是精细化的资源调度编排策略及 QoS 感知策略智能的资源超卖以更低成本满足计算任务对计算资源的需求并保证计算效率的同时不影响延迟敏感服务的响应时间上图是 Koordinator 混部资源超卖模型也是混部最关键最核心的地方。其中超卖的基本思想是去利用那些已分配但未使用的资源来运行低优先级的任务如图所示的四条线分别是
limit: 灰色高优先级 Pod 申请的资源量对应 kubernetes 的 Pod requestusage: 红色Pod 实际使用的资源量横轴是时间线红线也就是 Pod 负载随时间的波动曲线short-term reservation: 深蓝色是基于 usage 过去一段时间较短的资源使用情况对其未来一段时间的资源使用情况的预估reservation 与 limit 之间也就是已分配未使用预估未来一段时间也不会使用的资源可以用于运行短生命周期批处理任务long-term reservation: 浅蓝色类似于 short-term reservation 但预估使用的历史周期较长从 reservation 到 limit 之间的资源可用于较长生命周期的任务其可用资源相比 short-term 更少但稳定性更高
这一套资源模型支撑了阿里巴巴内部全业务的混部足够精炼的同时也具备很强的灵活性。Koordinator 整个混部资源调度的大厦构建在这样一个资源模型的基础之上配合上优先级抢占、负载感知、干扰识别和 QoS 保障技术构建出混部资源调度底层核心系统。Koordinator 社区将围绕这个思路投入建设持续将混部场景的调度能力展开将阿里巴巴内部丰富场景支持的经验输出到社区解决企业面临的真实业务场景问题。
3 双零侵入超低接入成本
企业接入混部最大的挑战是如何让应用跑在混部平台之上这第一步的门槛往往是最大的拦路虎。Koordinator 针对这一问题结合内部生产实践经验设计了“双零侵入”的混部调度系统。
第一个零侵入是指对 Kubernetes 平台的零侵入。行业内的人大多知道将 Kubernetes 应用于企业内部的复杂场景混部时因为这样或者那样的原因总是需要对 Kubernetes 做一定量的修改特别是节点管理Kubelet部分这部分修改本身具备较大的技术门槛同时也为给后续的 Kubernetes 版本升级带来巨大的挑战。企业为了解决这一问题往往需要专门的团队来维护这一些定制化的修改并且具备很大的沉默成本等到线上出现问题或者需要升级新版本时熟悉这份修改的同学可能已不知去向。这给企业带来了很大的技术风险往往让混部技术的推广受阻。而 Koordinator 混部系统设计之处即保证了不需要对社区原生 Kubernetes 做任何修改只需要一键安装 Koordinator 组件到集群中不需要做任何配置既可以为 Kubernetes 集群带来混部的能力。同时在用户不启用混部能力时不会对原有的 Kubernetes 集群有任何形式的打扰。
第二个零侵入是指对工作负载编排系统的零侵入。想像一下在企业内部的 Kubernetes 集群之上提供混部能力之后将面临的问题是如何将企业的工作负载接入进来以混部的方式运行。一般情况下将会面临的两种情况是
工作负载具备企业私有运维特性由平台或运维团队的系统管理这些工作负载的日常升级发布、扩容缩容而企业推进混部的容器或 SRE 团队与平台运维团队之间存在着组织的鸿沟或大或小如何推动平台团队改造工作负载管理机制对接混部的协议也是一个不小的挑战。工作负载以原生的 Deployment/StatefulSet/Job 的方式管理对其 Kubernetes 内部的设计实现或改造成本超出了团队的预期也将成为推行混部的挑战。
Koordinator 针对应用接入层的改造成本设计了单独的工作负载接入层Colocation Profile帮助用户解决工作负载接入混部的难题用户只需要管理混部的配置YAML即可灵活的调度编排哪些任务以混部的方式运行在集群中非常的简单且灵活。当前 Koordinator 为用户提供了混跑 Spark 任务的样例未来社区将持续丰富工作负载接入层的特性支持更多场景的零侵入接入。
4 云上、云下一致的用户体验
Koordinator 开源项目是阿里巴巴云原生 2.0 的重点战役用户除在自己的环境中可以体验到 Koordinator 混部带来的技术红利也可以将其部署到任意一个云厂商中保持混合云、多云的架构一致。当然也可以在阿里巴巴提供的多款云产品中获得一致的用户体验一次设计对接多处发挥价值。 可以看到除了支持内部超大规模的业务混部外Koordinator 也是阿里云容器服务集成的解决方案社区将持续的保持活力致力于将混部变成平民化、通用化、标准化的技术能力。
三 为什么要开源
最早做容器混部的是 Borg 在 Google 内部运行超过 15 年最新公开的资料是 Borg: the next Generation[1]。国内互联网公司内部推进混部接近 10 年其中阿里巴巴的混部技术也经历过了 3 代技术架构升级变迁最终走到全局混部的终极形态。混部帮助阿里巴巴的电商、搜索、大数据业务极大的提高了大促的备战效率也为历年的双 11 大促节省了大量的计算资源。
我们坚信云原生混部是企业容器调度技术发展的必然方向只有通过工作负载的混合编排才能在业务多可用区灾备架构下实现更好的资源利用效率才能充分的发挥不同类型负载的削峰填谷效应从而完全的发挥出计算资源潜力最大化释放云计算的价值。 Koordinator 的开源希望让更多的企业能够看见并用上云原生混部的能力帮助企业加速云原生化的过程。在技术上Koordinator 能够帮助企业实现更多的负载能够接入到 Kubernetes 平台丰富容器调度的工作负载类型继而发挥出工作负载错峰分时的特征从而实现效率、成本上的收益保持长期可持续发展的健康形态。
当前Koordinator 已经支持了 Spark 任务场景的混部同时也提供了低成本接入混部的解决方案期待看到你的混部应用案例听到你的反馈未来Koordinator 社区将持续的丰富混部的场景及业务形态支持 Flink、Hadoop、AI Jobs、音视频任务等尽情期待。
原文链接
本文为阿里云原创内容未经允许不得转载。
