混部开源 Koordinator 背后的故事|学习笔记(一)

简介: 快速学习混部开源 Koordinator 背后的故事

开发者学堂课程【云原生技术趋势与行业发展解混部开源 Koordinator 背后的故事】学习笔记,与课程紧密联系,让用户快速学习知识。

课程地址:https://developer.aliyun.com/learning/course/1035/detail/15147


混部开源 Koordinator 背后的故事

 

内容介绍:

一、什么是混部

二、为什么要混部

三、如何能够便捷的构建混部并且拿到业务成本效益

四、Koodinator 是什么

五、Koodinator 包含内容

六、Koodinator 整体架构

七、Koodinator 优势

八、Koodinator 关键技术

九、Koodinator 上下游

十、Koodinator 社区

十一、企业混部应用经验分享

十二、互动与讨论

十三、Q&A 环节

 

一、什么是混部

(1)混部定义

混部的定义可以分别从两个角度出发,第一个角度为基于节点粒度的定义,即为单个节点或者单机的维度在多个容器能部署在一个节点上,或者多种应用部署在一个节点上,此部分呢即为巩固。

多个容器即就包含了容器有多种类型,例如容器按照容器中所装载的业务的种类不同,会分成在线、离线或者在离线三种形态,并不仅仅限于之前所常规理解的离线容器,所以多种容器即为只要在单机上放置的应用或者是容器的种类超过一个,其都属于Google 的范畴。第二个部分为单个节点,单个节点即为能够运行容器的最小单位。因为现在拥有云的多种形态,其中包括资源形态也变化很多种,所以其会包含物理机、单个ECS、单个弹性容器等等。

混部基于集群粒度的定义为多种应用可能在一个集群内实现自动部署,其不同于离线独占一个集群或者在线独占一个集群,其为多种类型的形态、多种类型的资源或者多种业务种类分布在一个区域内,在一个区域内实现弹性,然后整个集群的资源是为所有的应用、容器甚至多种业务方提供服务,通过预测分析应用特征,能够实现业务之间的错峰填谷。简而言之,只要存在"多",即为混部的概念。

其实在许多情况下,个人表达一个确切的含义其实即为个人希望去把整个调度系统做得更好。其实任何一个调度系统,其往下去做,其自然而然都会想到混部的方向,因为提高资源利用率一定为调度系统的一个重要的目标之一。

在整个调度系统之上,通常情况其都存在一些延迟敏感性的服务,此为slice 里面左侧绿色的部分,其可能会表现出一些特征,典型的特征为其的规格会相对在集群公司偏大一点,例如有四核、四核8G 或者两核4G 等更大规格。对应此处提及比较形象的内容为例如个人在一个容器里面装较大鹅卵石的概念。同时,当集群规模相对较大后,在集群内部会出现一些大数据计算类的作业。此类型的作业通常表现出特征为相对而言较小的规格,此处将较小规格与较大的规格混合并放到一个集群在一个节点上去跑的时候,其就类似于个人将鹅卵石和沙子装在一起,使得其整体并不需要更大的一个容器,但是其可以使得两种不同类型的任务都去混跑。随着业务的不断演进,除了延迟敏感性服务和批处理计算以外,还有AI 业务也要引起重视。

在整个业务支持情况里面,可能也会遇到实时类的计算,例如flink 实时计算流或者是ai 的workload,其所表现出的规格相对而言并非那么小,但有些顾客甚至为更大。此只为整体在总部里面可能面临的一些典型的业务形态,当个人将所有的业务形态装到同样一个集训之后,此时集训的资源并不等于所有资源的加总,因为在其之间存在着互补特性。例如fance 特征的重合。从而导致个人可以使用更少的资源将所有的任务运行起来,也即为最终混部达到的样本基本的原理。

(2)混部的核心技术

第一部分为节点粒度。节点粒度为与个人关系最多的内容,在单节点上,两个容器或者多个容器放置在一起,个人的干扰、可靠性和稳定性如何保障即为容器隔离技术。容器隔离技术衍生了许多当前常见的容器,例如袋鼠、RunC 等。

其次为单机调度技术。单机的调度技术即为单机上存载了整机资源的管理,即整机链的资源管理,由此其会有单机的负载感知、容器策略和阈值设置、容器优先级和伸缩控制,cpushare 等。

其次为中心调度技术。中心调度技术即为个人能够在中心端去感知单机粒度的节点反馈、负载反馈、调度策略、调度性能的指标等。

最后为资源差异化SLO 技术,个人如何将资源的单机或者整机群的维度上,实现个人所有资源的差异化SLO 的设定,优先级的设定,以及对应的资源作业种类的匹配和中心调度进行配合,把个人整个单机上单节点的维度,将个人的容器放置并部署好。

第二部分为集群粒度。集群粒度之间可以被认为是在节点的力度之上来实现的整个集群的资源管理与混部,其中就包含了中心调度技术,中心调度技术包含高性能调度、资源视图、多负载的资源协同、GPU 拓扑感知等。其次为单机调度技术。

单机调度技术包含任务的高频起停控制,单机的多环境、多硬件的适配,cpu 的归一化等。此超出了单节点的范畴,在整个集群内适应多种单节点的情况下出现。

再其次为个人通常用到的使用K8S生态化框架和配套能力的建设,即为整个集群的规模,受险有k8s 框架,需要做一些突破和调整,整个K8S 生态系统的稳定性改进、运维的配套能力、界面和接口能力、业务对接等。

 

二、为什么要混部

进行混部的原因很简单,个人在混部的领域里面,通常看到的即为如何将资源的效率提升到最高,就叫混部了。所以混部通常为一个高优先级与低优先级放在一起,高于优的部分实现利用率的提升。将各种类型的资源跑出来,稳定运行的资源与超发的资源变为一部分是稳定的,另外一部分是强制性的资源,整体来支持利用率的提升。

阿里混部技术经过多年的发展,产生了许多业界广为认可的成果。Google Borg 实现大约超过15年的时间,中国国内在大规模推进混部的时间接近10年。阿里混部已经走过了3代主流技术,即为Sigma 时代、AlphaAS 时代与云原生统一调度时代。

其实阿里经过三个阶段的演进与积累,其也并不希望再从头重新经历一遍三大技术的迭代,经历从单机的非容器化到变成容器化,再从容器化变成抢占式,再变成双调度器的协同式的过程。阿里希望个人能够直接采用第三代的积累和经验。采用基于K8S 的云原生统一调度,然后采用单一的调度器,来实现整体单一的调度系统,从而实现多任务、多负载的协同感知,最后实现阿里整个稳步的效果。此过程经过实践证明,其也是目前最理想的架构与最好的一个工程实现。

image.gif


三、如何能够便捷的构建混部并且拿到业务成本效益

在日常生活中,其实大部分人在很多领域里面都会非常关心如何能够做到混部或者怎样能够最快的拿到混部之后的业务收益,由于混部从定义角度出发很简单,但从实现角度出发仍具有各种挑战,混部的许多技术并不是一个团队能够从头到尾、从底层到上层所有的应用,包k8s 生态站、内核技术等全部都能够掌握的,并且此将涉及到业务层面与整个系统的方方面面,由此个人如何操作是最快与最容易实现一个混部或者是最容易得到混部的结果。

为了达成目的,个人有两条路径可供选择。

第一个路径为直接采用公有云或商业化的产品,此处默认带了一些混部与弹性能力的支持。

第二个路径为结合从团队自荐和开源社区的角度出发,所推荐的方式即为开源共建,此方式既可以保证团队拿到团队自建的效果,使得个人对于整体的技术有了解、掌握、延展的发展及延续发展的能力。

第二个部分其又可以借助开源社区用户所积累出的各层技术站的经验,在当团队里面没有足够多的精力或者人才储备的情况下,即可使用开源社区已经积累与打磨好的技术做业务的直接应用。由此,当前Koodinator 社区其实就是基于此背景进行设计和推出的。

image.gif

 

四、Koodinator 是什么

Koodinator 名字取自英文的coordinator,k 是用来替换掉的c 的,因为整体上云原生的混部是基于Kubernetes 平台上做的,因此Koordinator 得以命名。Coordinator 本身具有协调的含义,因为要进行混部,即为要将集群里面的各种工作负担协调的非常的好,使得其都能够获得自身的运行质量,与此同时,对于集训而言,个人也能够使整体所有计算资源能够得到充分的发挥。

个人可以将混部理解成在Kubernetes 之上做的一套可以帮助大家个人提高部署密度、降低资源成本的容器编排解决方案。阿里进行混部是非常早的,阿里从2016年开始探索混部的技术。阿里混部经过了很多年的发展,其帮助2021年"双十一"计算成本下降50%。四都要去发布。

整个Koordinator 项目在2022年4月6日正式对外发布。Koodinator 项目的技术基础为来源于阿里内部多年的实践经验,整套系统的设计其中包括架构上和设计思路上,都为从阿里生产环境中积累的多年经验。

 

五、Koodinator 包含内容

目前Koodinator 项目里面包含的内容分成三个部分。第一部分为差异化SLO,就整体差异化而言,其技术涵盖的内容指个人会在Kubernetes 之上,抽象一套面向QoS 的资源调度机制。简而言之,个人会将整个集训的资源划分出不同的等级,即为不同的优先级,然后在每个优先级内部会划分出不同的QoS,此即对应着不同资源类型的不同隔离的等级。整套差异化技术目的为帮助个人在Kubernetes 里面定义出不同的优先级和QoS 并且保障每一个优先级和QoS 的资源特性。

第二部分为资源精细调度。资源精细化调度来自于阿里内部编排了较多的应用之后,阿里沉淀的一些典型的应用编排经验,包括可能为应用对调度的诉求或者应用对运行时的诉求,比如:CPU 拓扑感知、性能优化类的调度能力、资源预留、交互式抢占、碎片整理、资源预览、CPU 共享调度、算力归一等。

第三部分为任务调度。当个人在运行一些大数据或者AI,比如pencil flow 的job 的时候,实际上,对于底层资源调度是有更多诉求的。比如个人可能需要同时调度多个pord,此为Gang 的调度。也存在一些不需要Gang,但其需要做批量的交付,以此满足其性能诉求。其也会存在优先级调度,包括弹性的Quota (队列间借用),也可能为内部常提及允许Quotaw 之间存在相互借用,从而使得整个集群资源被个人更好的使用。

整体而言,Koodinator 包含的三部分技术内容,个人希望通过开源推进整个混部技术的标准化,也使得更多的用户去使用。

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
4月前
|
Kubernetes 监控 Cloud Native
eBPF技术大揭秘:一张全景图彻底改变Kubernetes问题排查,助你成为云原生时代的超级英雄!
【8月更文挑战第8天】在云原生时代,Kubernetes作为容器编排的标准,其问题排查变得日益复杂。eBPF技术无需改动内核即可编写高效、安全的内核程序,实现系统细粒度观测与控制。近期发布的基于eBPF的Kubernetes问题排查全景图,展示了如何利用eBPF监控资源使用、网络性能及调度策略等,例如通过eBPF程序监控CPU使用率。此全景图有助于快速定位如高CPU使用率等问题所在Pod,进而优化配置或调整调度。
123 8
|
资源调度 调度 混合部署
Koordinator 助力云原生应用性能提升,小红书混部技术实践
本文基于 2023 云栖大会上关于 Koordinator 分享的实录,介绍小红书通过规模化落地混部技术来大幅提升集群资源效能,降低业务资源成本。
|
编解码 人工智能 Kubernetes
混部开源 Koordinator 背后的故事|学习笔记(二)
快速学习混部开源 Koordinator 背后的故事
混部开源 Koordinator 背后的故事|学习笔记(二)
|
存储 弹性计算 Cloud Native
混部开源 Koordinator 背后的故事|学习笔记(三)
快速学习混部开源 Koordinator 背后的故事
混部开源 Koordinator 背后的故事|学习笔记(三)
|
存储 机器学习/深度学习 弹性计算
混部开源 Koordinator 背后的故事|学习笔记(四)
快速学习混部开源 Koordinator 背后的故事
|
运维 Kubernetes Cloud Native
读书笔记 | serverless技术解析与落地实践
读书笔记 | serverless技术解析与落地实践
157 0
|
人工智能 运维 Kubernetes
从 KubeVela 谈起:云原生应用交付会怎样发展|学习笔记(二)
快速学习从 KubeVela 谈起:云原生应用交付会怎样发展
从 KubeVela 谈起:云原生应用交付会怎样发展|学习笔记(二)
|
存储 Kubernetes Cloud Native
从 KubeVela 谈起:云原生应用交付会怎样发展|学习笔记(四)
快速学习从 KubeVela 谈起:云原生应用交付会怎样发展
从 KubeVela 谈起:云原生应用交付会怎样发展|学习笔记(四)
|
存储 运维 Cloud Native
从 KubeVela 谈起:云原生应用交付会怎样发展|学习笔记(一)
快速学习从 KubeVela 谈起:云原生应用交付会怎样发展
从 KubeVela 谈起:云原生应用交付会怎样发展|学习笔记(一)
|
运维 Kubernetes Cloud Native
从 KubeVela 谈起:云原生应用交付会怎样发展|学习笔记(三)
快速学习从 KubeVela 谈起:云原生应用交付会怎样发展
从 KubeVela 谈起:云原生应用交付会怎样发展|学习笔记(三)
下一篇
DataWorks