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

本文涉及的产品
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
简介: 快速学习混部开源 Koordinator 背后的故事

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

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


混部开源 Koordinator 背后的故事

六、Koodinator 整体架构

目前Koodinator 整体架构为下图所示。在整个项目的技术上划分成三大块,最底下部分为code net 模块,其负责对应单机的技术能力。例如对于应用的特征感知、单机级别的干扰检测、QoS 的管理、单击的资源隔离、根据根据Linux内核的特性去做的资源调优的能力,其都会沉淀到Koodinator 的组件里面。在单机上会再扩展出一些运行时管理者的角色,以此帮助个人适配各种不同的运行,同时也可以避免个人对于底层基础的组件进行侵入式的修改。在最下部分之上,中心端会有两个主要的角色,其中左部分的角色为Koodinator 的schedulener。

整体的Koodinator Schedule 里面包含两部分内容,一部分为前面所提及调度的一些特性,比如任务调度、Gang 等。第二部分为从调度的特性,在实际操作中,个人进行调度较多,但是进行从调度为较少的,然而从调度在整个混部的项目中是非常关键的内容,从调度能够保证整个集群的资源运行质量持续保持到一个位置的非常关键的一环。

中心的第二部分为code manager,此组件用于做整个混部策略的管理,包括工作负载如何接入混部框架,整体的不同节点的slo 如何管理及每个节点的slo 如何管理。

另外,个人也在Koodinator manage 里面汇集成一个资源画像的模块,其是为了更好的支持调度器做更好的资源打散,以此避免局部的机器出现一些热点,从而导致服务受损。Koordinator 整体通过此几个模块,实际上能够帮助个人解决两大问题。第一个问题为个人如何将混部的工作负载接进来。

例如在此图里也写到了微服务、有状态的APP、大数据、AI 内的job、IOT 及语音视频转码类任务,如何使此些任务以最低成本的方式进入整个Koodinator 混部的框架中为整体架构解决的第一大问题。

第二大问题为如何使得任务在混部的时候各自都能够运行好,计算任务能够获得自己需要的算力,在线任务运行的延迟不受到影响。

image.gif

 

七、Koodinator 优势

Koodinator 的第一个优势为之前所提及的内容,因为整体的项目实际上来源于阿里内部大规模的生产实践,即为目前整体的天猫淘宝搜索广告大数据及数据库中间件,实际上都为基于云原生容器调度的方式运行的,而底层的技术站都是基于一套混部资源调度的方式,底层会有不同的计算设备,例如比如裸金属、vm 及各种各样异构的计算资源。中心都为通过同样的一套调度架构支持起来的。

目前整个阿里内部上市具备非常大的规模,总体规模非常大,单个集群规模也会很大。单单一个集群可能就会超过百万cpu 的规模。此外,当个人在大规模底下进行任务调度时,其也会具有超高的性能诉求。整体目前的技术水位在峰值的时候会出现每秒需要调动2万个任务的情形。

统一调度帮助阿里双11大促成本降低50%,生态环境常态CPU 利用率65%领跑行业。通过阿里内部较高的业务需求的沉淀,锤炼出来整套的混部能力。

image.gifKoodinator 第二个优势为当前业内将关注度聚焦到混部技术最核心的一层里面。在调度系统之上,个人可操作的事情是很多的,例如工作发展介入、资源的弹性、智能成本的管理、额度配额的管理及整体资源的运营等等。但是Koodinator 项目会将中心聚焦到混部技术之上,即为解决前面提及的两大问题,通过前面提及的三大技术方案去做的。

image.gif另外一个为整个Koodinator 项目实际上具有两个较为重要的特性。第一个特性为个人对应用工作负担的管理是零侵入的。此对应前面提及的Koodinator 具有一层专门去研究如何使用低成本接入到混部的系统中的方案。当个人在公司内部推进混部技术的时候,个人会面临很多挑战,其中的一个很大的挑战即为个人如何使得工作负载能够以混部的方式进入。

由此,个人可能需要找到对应的团队或者个人独立完成,但是个人可能对于spark 任务于tf 任务如何运行较为陌生。Koodinator 会投入相当大的精力,其会帮助个人将典型计算类的负载如何混部的整个链路打通,然后用户只需要经过简单的配置,就可以自动的将混部的任务转化成计算和混部的任务,从而避免个人对计算框架进行修改,此可以帮助个人更快的将混部在资企业内部的场景去落地。

image.gif第二个零侵入值为对整个Kubernetes 是无侵入的,即为在Koodinator 支持的Kubernetes 版本上,用户都可以将开源组件安装到自己Kubernetes 集群,从而获得对应的能力。

因为Kubernetes 本身的扩展性在中心端是较好的,但是在结点端相对的扩展性较差,所以在Koodinator 项目里面,个人将会专门做一个在Kubernetes 和底层容器运行时之间做一个hook manager,其专门用于支持个人进行策略的扩展,从而避免个人对于上层的Kubelet 以及底层的containerd 或docker 进行一些侵入式的修改。通过此种方式可以使得个人更好的获得混部的能力,同时不需要额外的维护Kubelet 以及底层容器运行时定制的特性。

当个人使用Koodinator,比如个人在企业内部将此技术运用,则个人可能会有多云的架构,或者个人拥有自有的资源,也有云上的资源,此时整套的系统会以何种的方式支持与运行Koodinator 系统。因为整体Koodinatork 为开源的系统,个人可以把Koodinator 部署到云上,从而获得混部的体验。

同时个人在阿里云上也提供了不同混部的产品形态,其可以帮助到个人获得更好的混部体验。比如最佳实践、混部典型的管理经验或者工具等。整体阿里云对外提供混部的产品形态有三种,第一种就是公共云。

第一种为公共云,即当个人在阿里云控制台购买对应容器服务之后,即可体验到整个阿里云提供的混部能力,其也会与Koodinator 系统保持完全的兼容,即用户从云下到云上的过程是顺畅的,该过程不需要做任何的修改。

阿里云也会提供敏捷版的产品形态,如果用户有自由的环境,并且接入到了阿里云的敏捷版里面,个人可以获得一样的混部能力啊。第三种为其会与合作伙伴进行合作的一体机的形态,客户可以通过购买一体机去获得整个完整的技术栈的超能力。

 

八、Koodinator 关键技术

实际上,整个混部里面最为重要的第一件事情即为资源模型。在整个混部里面个人如何进行混部,实际上最本质的就为个人要进行差异化能力。

通过资源超发,能够提高资源的利用率。在资源超发中,此处为整体Koodinator 的资源模型。此图中红色部分代表一个典型的容器,比如一个在线的容器,其资源使用率随着时间波动的情况,其使用率有时候会低一点,有时候会高一点,其也会有折线的抖动。混部最关键的技术在于其会对时间序列的数据进行分析与预测,然后将已经分配但是用户没有使用的资源,即为在一段时间内实际上是可以被再次利用的资源挖掘出来,从而支持个人所进行的计算任务。在挖掘计算资源的时候,个人会有不同的策略,比如此图对应靠下方的蓝色线,其对应的内容为周期比较短的预测,其可以拿到更多的资源,但是相对而言稳定性较差。绿色的线对应为周期相对较长的预测模型,其可以获得非常稳定的资源。在Koodinator 里面定义的资源模型是非常完备的,其可以支持在线服务、实时计算、AI 的训练任务、批处理的计算任务及测试的任务。

image.gif在整个混部当中,实际上大众关注度较高的为资源隔离技术。右图为Koodinator 在节点处组件的架构图,其中提供了各种资源纬度的资源的隔离技术,

image.gif例如CPU cpuset、CPU cfs_quota、CPU LLC、OS 优先级抢占、oom priority、memory qos、network bw/iops、network qos、blkio 等。

 

九、Koodinator 上下游

因为整Koordinator 的是基于Kubernetes 社区,但个人不会对Kubernetes 社区进行任何修改,所以个人在使用混部技术时,首先肯定会使用到Kubernetes,然后在Kubernetes 之上装上Koodinator 对应的组件。

image.gif个人社区提供的能力与企业内部真实环境需要的能力之间可能会存在一些dif,此时个人可以基于社区fork 自己内部的版本,然后结合企业自身的特性,例如可能个人存在历史债务或者当前spark 已经有一定的探索应用,其会兼容旧的场景,通过此种方式可以与Koodinator 社区进行更好的协作。

因为整体Koodinator 社区迭代速度较快,所以在此模式下,个人可以不断从社区获得新的特性并且只需要在内部的版本中维护自身企业非常特殊化的部分即可。

如果用户有许多共性问题存在,其也可以直接提到社区,社区即会跟进对应的问题并且将更多的能力通用化,从而避免个人在升级过程中不断进行维护的成本。

相关实践学习
容器服务Serverless版ACK Serverless 快速入门:在线魔方应用部署和监控
通过本实验,您将了解到容器服务Serverless版ACK Serverless 的基本产品能力,即可以实现快速部署一个在线魔方应用,并借助阿里云容器服务成熟的产品生态,实现在线应用的企业级监控,提升应用稳定性。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
人工智能 资源调度 Kubernetes
混部开源 Koordinator 背后的故事|学习笔记(一)
快速学习混部开源 Koordinator 背后的故事
500 0
混部开源 Koordinator 背后的故事|学习笔记(一)
|
12月前
|
Kubernetes 监控 Cloud Native
【勝讯云 Finops Crane 集训营】之集群优化实战
【勝讯云 Finops Crane 集训营】之集群优化实战
107 0
|
存储 弹性计算 Cloud Native
混部开源 Koordinator 背后的故事|学习笔记(三)
快速学习混部开源 Koordinator 背后的故事
197 0
混部开源 Koordinator 背后的故事|学习笔记(三)
|
存储 机器学习/深度学习 弹性计算
混部开源 Koordinator 背后的故事|学习笔记(四)
快速学习混部开源 Koordinator 背后的故事
297 0
|
存储 运维 Cloud Native
从 KubeVela 谈起:云原生应用交付会怎样发展|学习笔记(一)
快速学习从 KubeVela 谈起:云原生应用交付会怎样发展
1694 0
从 KubeVela 谈起:云原生应用交付会怎样发展|学习笔记(一)
|
运维 Kubernetes Cloud Native
从 KubeVela 谈起:云原生应用交付会怎样发展|学习笔记(三)
快速学习从 KubeVela 谈起:云原生应用交付会怎样发展
1632 0
从 KubeVela 谈起:云原生应用交付会怎样发展|学习笔记(三)
|
存储 Kubernetes Cloud Native
从 KubeVela 谈起:云原生应用交付会怎样发展|学习笔记(四)
快速学习从 KubeVela 谈起:云原生应用交付会怎样发展
1709 0
从 KubeVela 谈起:云原生应用交付会怎样发展|学习笔记(四)
|
人工智能 运维 Kubernetes
从 KubeVela 谈起:云原生应用交付会怎样发展|学习笔记(二)
快速学习从 KubeVela 谈起:云原生应用交付会怎样发展
1636 0
从 KubeVela 谈起:云原生应用交付会怎样发展|学习笔记(二)
|
存储 运维 Kubernetes
从开源技术 KubeVela 谈起:云原生应用交付会怎样发展|学习笔记(一)
快速学习从开源技术 KubeVela 谈起:云原生应用交付会怎样发展。
1785 0
|
存储 运维 Kubernetes
从开源技术 KubeVela 谈起:云原生应用交付会怎样发展|学习笔记(三)
快速学习从开源技术 KubeVela 谈起:云原生应用交付会怎样发展。
1938 0