喂好 那我们就那个分享就开始了那个我就是各位观众嘉宾然后各位原生的爱好者 大家好就是今天我是来自阿里云的韩如刚然后旁边这位是来自英特尔的张康大家好那个我俩今天给大家来分享的是那个就是使用一个可叉拔的可定制的智能运行室然后来去增强工作负载的服务质量这样一个topic我们今天的分享主要内容大概是以下的这六小节前面我们会给大家有一个简单的背景的介绍然后后面我们会中间两节我们会重点去介绍我们增强工作负载那个服务质量的一个方法和一些技术上的设计然后到处第二节我们会给大家有一个简单的demo然后最后会QA环节首先想为大家指出的一个现状是在大规模的那个Kubernetes的集群上然后现在有两点需要注意的特点一个是那个就是在大规模的Kubernetes集群上已经普遍地存在工作负载的统一的整合的部署我们可以看到就是在Kubernetes集群上现在会有我们会把各种各样的那个工作负载然后部署在它的一个集群的进行调度比如说有那个微服务的那个应用然后有有状态的然后有大数以ai的然后还有那些创新型的应用然后它Kubernetes集群下可能承载的各种各样的一些物理的ai色的环境比如说是迅速机VM然后或者说是裸金属的服务器以及一些弹性的一些新型的一些比如说弹性容器实力E3A这样的一个环境然后另一个特点呢则是说在大规模集群上现在有普遍存在着就是我们对集群的资源利用率的一个提升这是一个那个VM VR在2023年的一个报告这指出了一个现状是说50%的那个Kubernetes的用户是使用Kubernetes进行集群资源利用率的一个提升然后还有37%的用户会使用它的一个混布的模型然后去提升资源的效率然后这两点分别会带来资源的需求上和资源管理上的一些挑战据说来讲第一 功能犯来的整合部署它会带来各种各样丰富的资源的需求一个例子是说典型的我们知道那个在线的服务比如说外部服务然后这样的一些应用他们通常的那一类功能负载的特点是说他们可能是延迟敏感的然后他们的利用率可能是随着时间的流量就随着一天的流量波动然后他们会有一个利用率的一个波动然后所以他们也通常存在一个特点说他们可能是 over provisioned他们可能会填写比较大的一个 request limit然后来去满足他们一个峰值的一个资源需求然后我们常见的一些P数里的负载他们可能通常是计算密集性的然后他们对吞吐有一定的要求但他们同时也有一个特点是他们可能对短比如说毫秒级的一个RT的影响是一个相对容忍的然后另外就是新兴的AI训练的作业任务然后他们可能又带来各种不一样的一些资源的需求比如说他们可能申请的是GPURDMA这样的一些资源然后他们这些资源可能是易购的然后会存在着够质样的硬件拓谱的差异然后会带来资源需求的进一步的一个复杂化然后高的资源利用率则带来一些挑战是说我们可以看到就是随着节点资源利用率一个提升其实炮的监和炮的内的一个资源的竞争然后其实是会带来更大的一个挑战比如典型的我们许多大规模的企业都知道我们现在在做工作负载的一些在地线的混布什么是在地线混布呢就是说我们去利用刚前面说的在线服务的一个它的利用率随天级的利用率的一个波动它可能存在比较多的一个空闲资源然后在某一时刻没有使用然后我们会利用Batch资源这样对资源容忍的一个特征然后将它和在线服务部署在一个节点上然后来去填充在意服务显示的那部分空闲资源然后来去改善整体集群的一个资源利用率然后达到一个集群资源利用率的提升对CPU资源等物理资源进行一个分数复用然后但是这也其实也引来了一个著名的Noise Neighbor的问题比如说我们在混布之后其实一个节点上它可能是通常是部署了超出这个节点上物理资源的容量的一个资源需求的泡的比如说CPU资源它通常可能是超卖的然后另外就是节点上的混布情况下可能很多资源是缺乏一个有效的隔离的比如说SMT的一些执行单元然后以及Las Vegas然后比如Las Vegas这样的一个在New Mano的维度的一个share的资源然后以及内存在关这样的它们是缺乏一个隔离的然后这就带来了我们今天要讲的一个关键要解决的问题是节点资源管理的挑战我们可以看到现在的Kubernetes在1.28项的一个现状Kubernetes提供的是什么样一个资源模型呢是首先它提供的Resource Requirements它其中提供了两个自断语意一个是RequestRequest指它在容器在节点上能确保能获得的一个资源然后Limits则是说的是容器在节点上使用的资源永远不能超过的上限Kubernetes基于它这Request Limits两个自断的语意它隐释的会给一个泡的得到三种服务质量的等级Garantee的Burstball和Best Effort这三种等级Garantee的顾名思绪就是它其实是希望你这个泡的资源得到最好的保障然后它也是服务质量最高的然后它需要你的泡的各容器的RequestCPU Memory的Request Limits都设置且相等Best Effort也比较好理解就是它其实是需要你这个泡的就是它不需要有太好的保障它尽力去做保障然后这时候Programmatis的一个隐释的得到的含义是说它要求你的Request Limits它CPU Memory的Request Limits都没有设置然后Best Effort就是为这两者之间的一个QS的等级对 就是下面这样一个示意图然后我们把这样的一个当前提供的一个资源模型然后带入到我们前面说的一个混布的一个场景我们理所应当的我们会把在线服务去部署成较高的QS等级会部署成Garantee的或Best Effort的然后让它去满足它更好的一个资源的质量的需求然后对P数理作业我们通常可能会将它部署成Best Effort的一个QS然后用Best Effort这种特性然后来去填充节点上空闲的一些空闲资源然后来去改善整个集群的一个资源用率但结果会什么样呢结果就是没有人会得到特别开心地去做混布首先对在线服务来讲它的很多物理资源不可避免地会增强比如说前面说到的像SMP的执行单元然后还有默计缓存还有内存单款这些资源它现在当然是缺乏隔离的然后当它们混布之后在线服务的这些贡源资源它会不可免费Best Effort作业去增强然后会导致它的RT成到波动影响然后对P数理作业它则会有一个比较差的性能表现为什么呢第一 首先我们现在在Best Effort这样的混布模式下我们不知道一个节点上其实到底有多少适合的Best Effort作业去部署但其实我们肯定能知道一个节点上复杂的高低不同对一个Best Effort它跑上去的一个好坏是不一样的然后第二呢就是我们也对B1炮的之间以及Best Effort炮的之间它缺乏一个公平性的保证因为我们的Best Effort炮的是没有Request Limits的然后我们其实也不知道但是我们实际的作业炮的其实是有大规格和小规格的真正的差异之分的但是我们现在没有这样保证他们都是在节点上被当做类似的资源隔离的配置对 然后所以前述的Noise neighbor的问题会依然存在如果这些账目呢它继续去分配一些比如说GPU资源呢这会怎么样呢我们当前有一些GPU资源的一些资源管理的方案比如说比较传统的是Device Powering加Rap RuntimeRap Runtime也是指比如说Invada DockerInvada 2K之类的在Runtime上做了一个比较多GPU管理的一些封装的逻辑的这样的一个Runtime这是一种方案然后另一种方案是社区最新比较提到的DRA就是Dynamic Resource Education这两种方案呢他们其实在DRA中已经解决了就已经帮助地缓解了Device Powering中的一些调度上的一些灵活性的问题然后因为我们前述的Device Powering的一些很多的工作需要你在Rap Runtime去进行对不同的设备去进行改进但如果我们去对GPU的资源对设备的资源进行更复杂的一些管理比如说对QS Wear或者说对脱补感值的调度呢这时候DRA的他当前的一个资源描述可能也是缺乏没有那么好用的所以呢我们想去说就是我们想去改善那个Pout的服务质量我们想从两个方面去进行这样一个改善第一是我们想去提出一个更增强的资源模型来去帮助我们更好的进行混布进行QS的改善第二我们想去提供一个可插拔的机制来去针对各种各样类型的资源需求进行更好的管理下面这一节我会给大家主要去介绍我们去当前去增强PoutQ那个服务质量的一些方法首先为大家去介绍我们的一个开源的调度系统的项目叫CodinatorCodinator主要是由R8开源的但是现在其实社区有比较多的企业包括小米、英特尔、IEA等一系列的企业然后都已经参与到开发之内然后它其实本身是一个面向QS感知以及混布附载的一个Codinator系统然后在部署在Codinator上然后它在我们当前的那个问题上其实它解决的什么问题呢它解决的是Codinator上集权上利用率提升的同时然后去降低缓解节点上资源增强干扰的这样一个问题对然后Codinator当前提供的一个架构是这样子的它主要包括那个控制面和节点测两方面的组件控制面当前主要有三个组件第一个组件是CodinatorCodinator可以简单的也就是一个Controller加Manager的一个组合的一个封装部署的套件Manager里面在我们当前解决的问题下主要是它会负责去对节点上不同的QS策略进行一个配置和管理它会告诉你每个节点需要对应什么样的QS策略然后另外很重要的一点是它会对节点上我们去进行混布的资源的数量进行一个计算然后在CoderScheduler这样一个组件其实则是我们基于社区的Scheduling Framework做的一系列的调度扩展的插件然后这些插件主要面向的场景也是我们Codinator解决的问题就是说QS杆织的调度然后以及设备的管理然后以及议购罪员调度CoderScheduler则是我们提供的一系列的重调度的插件然后它用来去帮助我们去在整个这样的一个QS杆织的调度情况下我们去解决一些节点上的一些重均衡然后和一些炮的SLAD保证问题我们在单击测有两个组件一个是CoderLate一个是CoderRenton ProxyCoderLate是我们单击的核心组件它就会具体地在单击测去做比如说节点和炮的上的资源利用率的一个刻画和采集收集上报然后并且它会根据CoderMander下发的节点的一个QS策略然后去进行节点上具体的QS参数的一些注入然后以及隔离的一些配置然后CoderRenton Proxy是位于Cooplate和CRI Runtime比如说CountedIs and Crawl然后这样的一些Runtime之间的一个代理然后它主要干的做事呢就是说它在位于CRI这个链路上的一个代理它允许CoderLate在CRI链路上去注入一些CRI的参数比如说我们去调节一个炮的它的一个CPU Calta然后以及它的一个CPU的权重等等然后Cultinator它其实当前提供了一系列的增强的资源模型和QS管理策略这里面首先我为大家介绍的第一个策略方案是BatterySauce这样一个方案这个其实核心就是解决我们前述的那个在离线混布情况下对Battery资源的一个资源管理的一个量化和节点上的隔离配置首先一方面呢我们前面说到我们遇到的一个Bee资源管理的一个关键问题是我们不知道节点上有多少适合调度的Bee资源然后所以我们这个方案我们的BatterySauce会去为节点上提供一个适合调度的Bee资源的一个容量的参考然后这个核心工作其实也是由我们刚才说的call the later和call the manager去做完成的另外对Bee的泡的调度我们其实也会去允许一个Bee泡的它去填写它的request limits然后只不过它是我们的一个可扩展资源就是Eccentric resources然后来去进行Bee资源的一个声明具体来讲它是长这样右边这个图就是一个Bee泡的它其实填写的是右边这样的一个压墓里面的红字的部分就是它填写的是Kumnanis batch CPU然后Kumnanis batch memory这样一个request limits然后我们会按这样的request limits去进行Bee泡的一个公平性和上线的保证然后这个Bee资源具体是怎么来的我可以给大家简单去介绍一下我们这样一个Bee的资源模型是左下边这个图我们从一个节点上常规来讲我们在上游基础的一个调度下然后我们可以看到节点最上面有一条黑线叫toto这个toto是指一个节点上实际可调度的物理资源的容量或者叫locatable然后其实另外我们通常会在调度系中关注比如说notary sauce fit那样一个调度插件里面我们会关注节点上已经分配了多少的资源就是这里面第二条从上往下第二条灰线allocated也就是说节点里分配的资源然后在基础的调度的notary sauce fit这样的一个调度插件里就是上游主流的一个账本交代的插件里面我们其实只允许一个节点继续去调度它前绿色部分就是toto-allocated之间的这一部分这也就是未分配的资源但是我们遇到我们前面说的灾烈线火步的这样的一个场景我们因为刚才说到在线的作业在线的应用在节点上通常是over provision就是说它可能一方面它可能有三点问题就是说它资源的填写上第一 它可能业务不知道填多少的request limits它可能填的request limits是偏大的然后第二就是业务可能知道它自己的应用在某一时刻有比较高的流量使用所以它 limits不能填得太小它可能要而且大家知道现在其实很多情况下我们不会对一个泡的对游戏对在线服务可能没法做特别频繁的比如说垂直伸缩所以我们 limits可能是为比如说较长一段比如说天际甚至周级的一个峰值去做准备的所以这个 limits会不可明显地填得比较大甚至request也填得很大然后我们另外的第三点可能大家很多都忽略到的就是一个齿化效应就是说我们其实一个节点上可能会属于多个泡的我们每个泡的利用率的峰值之合是远远要大于一个节点本身的利用率的一个峰值的然后这中间的这三个概谱其实都会导致自然的过度浪费然后我们想趋于上节点是调填充更多的batch作业去把这个空间自然利用上来我们怎么做呢我们其实知道batch的这些p 处理作业传统大数据作业它其实都是一个相对稍稍让你的作业然后我们其实只需要知道这个节点上这部分资源在比如说短周期的比如说10分钟内是一个有保障的资源就好了那所以我们现在怎么做呢我们会加了下面的一条蓝线这个部分首先最下面是红线是说我们节点上那些在线资源的一个实际的利用率蓝线部分则是我们会对这个红线的这部分做一个短周中短周期的一个峰值预测然后记录叫peak也就是说这是我们认为比如说这个当前节点上这些调度的在线作业它在未来10分钟内最高能用的一个用量然后在peak和allocated之间这部分也就是深绿色这部分其实就是我们能比较安全地去给batch作业去进行超卖调度的一个可附用的资源reclaimable然后我们其实我们提供的batch作业就是unallocated加reclaimable这部分资源为什么能提供unallocated因为我们其实大部分常见我们也允许batch作业去被抢占的然后第二个为大家介绍的一个增强的QS管理的策略是result control kills我们前一数其实有很多节点上的物理资源比如说last-level cache也就是默计缓存然后和内存带宽然后他们其实当前在原生的couplet和ci的管理下它是缺乏隔离的配置然后但是我们其实也知道现在有很多的硬件的特性比如说inter的RDT然后和amdkills和arm的ampamp他们都提供了比较一致的result control的接口然后来去管理这些硬件的资源然后我们其实现在也就基于这样的一个硬件机制去对针对性的对混布的情况对进行QS的限制据说来讲是我们现在比如我们cognitive中可以定义右边图这样的一个配置这是一个coffee map然后里面其实对下面的那个结构体beclass下面都是我们对节点上bepod的一个QS配置我们可以通过RDT通过amdkills等一些硬件机制去限制它的一个L3cache的一个使用的比例然后其实是路的比例因为是一个路化分然后另外是内存在宽的一个整体的百分比然后我们现在使用了一个比较普速的一个策略是一个静态划分的策略然后这也是考虑到就比较稍微早一些的RDT机制它其实支持的能力没有那么强大但是我们其实在现在比较新的比如说internet的机器上它其实已经更强大的RDT这也是我们后续会持续得点的一个QS策略然后另外我想为大家去介绍简单介绍的一个class增强的方案是我们会去对节点的各种资源的脱补感知进行增强比如我们知道社区的couplate有tropology manager我们其实可以对NUMA上的资源进行一个划分但是其实我们前面说到我们现在要去管理batch resource的资源但这个社区是肯定当前对batch effort是缺乏这样的一个比较好的保证的但是我们现在其实是允许cognitor提供了对bE资源进行NUMA aware的一个调度它允许我们去把一个bE的泡的它的能共享的河实际能跑到的河上这个集合其实会划分到一个或多的NUMA node上这也是我们现在能去支持的整体上来讲就是说我们对各种各样的资源进程问题我们其实可以不断地去发现有一些资源的一些性能或者增强问题然后我们会采用一个分而知之的策略然后会不断地去把它去拆解然后去解释成我们对应的一个策略其实在cognitor中它是对应了各种各样的一些plugging然后来我们去解决这样的问题然后我们前述的这样一个QS增强的策略其实也带来了具体的资源管理机制的一些需求第一呢就是我们其实在节点上会去管理各种各样常见的CPU资源例如CLS COTA然后CPU SET和Maver Limit这就对应了解点绑合CPU时间片还有内存上线之类的这些常见的CPU资源然后我们想去管理这些资源可能会遇到一些问题比如说这些资源通常是被cubulate和content runtime比如说content D然后是管理的然后我们想去做一个比较好的资源管理机制我们其实需要避免和这些就是主链路的资源管理机制去打架的我们想避免和它们冲突这是一点需求然后第二点是说我们其实想去提供一个尽可能贴近上游然后能开源的标准的一个资源管理的方案我们其实希望对cubulate和content runtime是无倾入的然后这也是我们重点需要在下面去介绍的我们分析的一个设计第三就是进一步的我们需要我们资源管理的状态是一个稳定的我们需要能和容器的状态持续去进行双分统布然后除了常见的cubul资源我们还在比如说二月场景然后以及别的各种各样的大家各种企业大规模企业的一些场景内我们会有一些out of trade的一些内核特性比如说我们的龙蟹内核提供了谷排灯类的这样一个混布的针对混布的一个CPU调度的优先级的一个机制我们也希望通过这样的一个资源管理机制进行统一的管理资源管理机制其实现在有一些比较多的就是下面四种方案其实都是对cubulate和continuous line相对无侵入的标准的第一就是设讯员最基础的其实是标准的CRI也就是cubulate加continuous line比如continuous D这样一套资源管理的链路然后但这样资源管理链路是显然是缺乏我们前面说的对B资源那些管理的然后另外三浪则是说在这条链路额外去部署一个单机的agent然后去自己手动地去直接去修改CPU资源CRI process 则是我们前述的coderon time process 这样一个方案我们去在cubulate和continuous line之间部署一个proxy然后去进行参数的一个调整注入NRI则是我们本次要重点去分享的我们其实是利用了continuous line社区一个重要的一个标准特性我们其实对上能解决前述的一些侵入性和以及部署方依用性的一些问题这部分下面就是由我旁边的那个张刚同学为大家介绍谢谢盧刚同学的介绍就是我这里就是正好就是刚才盧刚同学讲的就是标准的一些方案可能有一些有前述的机动所以说我们为什么会选择就是把NRI集成到coderon time上呢所以我们可以先看一看就是说这就是这种方式的一些区别和为什么会有这种方式说标准的这种CR requests的链路其实就是说从cobulate然后到continuous line time然后到low-level的continuous line time 对吧那么这样一条链路上我们怎么去做一些自定义的一些精细化的一些资源管理呢那首先我们想想那是不是可以最简单的最直接的可能就是旁路对吧那就是说我们单独一个load agent然后Eazer说我去一步地去更改这样的一些根据事件code或者contin的事件去一步地更改这样的资源或者是从我拿到这样的一个事件之后呢去call这个continuous line time去做这样的一些修改对吧这是一种方式就是旁路我们简单穿旁路另外一种方式呢是不是这条链路我们是不是可以在中间插入某个点那就是很明显就是proxy模式对吧我们在cobulate跟continuous line time之间然后我们插入一个proxy然后这样的话去节驰上游的CR requests然后把CR requests做一些对应的一些修改然后把我们的一些policy或者是config去apply下去然后这是一个然后当然还有一些其实是还有一些场景就说我们考虑一下就说这个链路上我们到底还可以在哪些地方去做一项这样一个hook呢其实还有一些厂商或者他们是在相当于在cobulate做一个hack对吧cobulate自己去改做一些轻容一些修改然后去可以去做一些相应的一些resource资源的一些update或者是config之类的当然这些可能就这样这种方式可能就是对cobulate有一些稍微有一些轻容性可能不符合前述的一些有刚同学说的一些需求所以我们就说提出NIN是不是可以其实另外一种方式就是说那我们除了在cobulate那是不是可以在continuous的地里面做一些事情对吧其实NIN就是在continuous的地里面做的事情它是一个它其实是OCR兼容的one time里面的一个plugin的一个framwork它当前的话其实已经在continuous的地的1.7和croud的1.26的版本已经支持了这样的一个feature然后就是说它其实是一个plugin的一个framwork然后支持用户可以去自定义去写一些插件然后跟continuous或者croud进行一些通讯然后去订阅一些pod或者continuous的一些事件拿到这样的一个事件之后plugin其实可以支持就是说你自己去写去更新一下ocs-spec然后更新ocs-spec之后返回给continuous的地让continuous的地的话就是继续把这些ocs-spec的change去merge到这个主链路上其实这样的话就是说整个主链路其实是没有动的我们跟通俗一点讲它可能就是在这条链路上在continuous的地里面打了几个洞然后我们把这些相应的修改去去改上去然后再由主链路去apply下去对 我们这里稍微比较一下就是说这几种方式有哪些优缺点吧比方说这个从功能完战性角度来说这个standalone模式其实它是因为它是跑路它其实不支持一些类似于GPU的环境变量的注入 对不对然后从可操作性和这种稳定性来讲Proximal是因为它是在这个链路上它又加了一个点这一点因为是实际上是自己加的所以它可能是对这种稳定性是一个问题比方说这个点如果挂了的话其实整个其他的CR requests那其实都没法walk了然后这是一个另外就是说Proximal模式其实是需要改couplet的系统参数然后再重启couplet所以这相对于来说对于运尾也是稍微一个增加力一点然后从实施性角度来说Proxy和NI其实是比较其实主链路上是比较实实的但是Standline就是一步的所以它会稍微有点实施性没有那么强当然你想要使用NI的话需要把肯定的diya或者是crownup to到一个相应的版本另外一个就是说由于Proxy其实是在主链路上其实是跟couplet是相对比较符合的所以它其实是一个适用于KBS的evolvent然后另外两个模式其实对于LongKBS的evolvent其实也是适用的所以我们就是其实是想要把NI提升到couplet然后当然NI也并不是一处而就的其实iPhonenet在CoupletCon它其实也是经历了三年了就是从21年的时候其实初步提出smarter run time的一个概念然后到2022年的时候NI正式地被merge到contentD和crown这个社区到2023年我们这个topic就是说我们其实是把NI提升到coupletnet去解决现实中现实世界的混沌的一些问题所以这是一脉相承的对然后我们接下来就说看看到底是NI怎么提升到coupletnet上其实NI提升到这部分的design是相对比较简单的其实我们就说把coupletnet作为一个NI的plugin我们去实现对应的NI plug-in接口然后通过NI的request的协议就是request and response跟contentD里面的NIadaptation进行一些交互然后这样子就是其实就这么简单整个流程就是这么简单但是然后当然我们是需要同时去实现一些NI的接口就是说去订阅NI的requestNI的一些订阅一些POD的事件比方说软POD sandboxcreatecontinent和updatecontinent当然这因为是其实现在是因为这个社区版本的coupletnet其实只用到了这三个事件但并不意味着说NI就只是这三个事件其实NI支持的还有很多其他的事件比方说PODpostcreatecontinent或postupdatecontinent或poststoppostunbox这些事件都是支持的然后我们就是其实这个feature已经被在coupletnet里面在1.3 release已经正式地去支持而且default has already leveled然后我们可以通过一个例子说看一下整个通过in-level NI之后workflow是一个什么样子的我们这里拿了一个之前有刚才说的batch resource这样一个plugin做例子这个batch resource plug-in其实它主要是操控的是这样子c-group的几个参数cpu的时间片或者是流行级还有memory的limit然后当然它订阅的其实是这样子的一个事件就是rampostunboxcreatecontinent和updatecontinent一个是post-level另外两个是continent-level的我们通过这右边这样的一个图我们其实可以看就是详细地看一下整个workflow是一个什么样子比方说create通过一个一个cr-request过来之后到content-d然后content-d会把cr-request通过这个cr-request提取出组装成一个lcs-back然后当content-d发现我实际上是有一些订阅事件比方说rampostunbox或者createcontinent的话它会把这样子的最开始的ocs-back去交给NIR的daptation然后NIRdaptation会把这个ocs-back组装成一个request通过RPC协议去发给couldnate然后couldnate呢其实就会发现假设我这是一个rampostunbox这个事件的话那我其实就是调用调用对应的事件事件的一个hook和它的handler然后这样子就是这里做的主要另外的工作就是说把ocs-back只转成couldnate-label的协议然后这样子交给后面的couldnate-label的自己的一些hook就可以去完成hook所需要的事情比方说这里的这个pluginbatch-source-plugin在port-level的话它就会去setport-level的一些c-group上述的一些c-group然后如果是createcontinent的话它其实是会它并不会自己去apply这些c-group它会把它组装成一个ocs-back然后通过ni-response返回给n-continu-d然后continu-d再去merge到这个主链路上的ocs-back这样子去通过软c-sh真正的去设置到底下的continu-continu的设Limit或者是request之类的这里需要指数的就是其实是ni-plugin的话其实是可以有多个的然后比方说就是跟couldnate-label同级的ni-plugin其实也可以有多个然后couldnate-label自己内部的根据订阅某一个事件的话也有自己的内部有很多的hawk-plugin所以其实是有这里是有两层的plugin机制的OK对 关于ni部分介绍到这里然后后面可能我们会有一个demo然后由刘光同学继续给大家介绍谢谢感谢张安同学的一个分享然后我后面下面会给大家有一个demo我们这个demo是一个简单的在历县混布的一个场景然后我们简单地混布的也做成一个lag然后由阿里云的云起实验室提供然后现在大家其实也是可以用自己的电脑去扫这个码然后去进行云起实验室的试用操作的就可以在实验环境去进行简单的混布的验证然后这块也具体地去使用了我们的colonatorOK我们首先这个场景是我们会没有头好的这个场景主要是给大家有一个简单的典型的在线应用我们会拿nix做替代然后我们离线应用是用一个视频转板用fmpack然后做一个替代然后我们在一个实验的环境其实这个规格比较小是个4C的一个环境然后我们会部署nix和fmpack的一个同节点的混布然后我们去看它nix的一个RT的性能首先我们这是一个nix的一个研谋然后我们现在这个节点上把nix部署起来了然后我们接下来会对nix有一个机械的一个性能压测就是我们其实是个nix自己跑的一个性能大家可以到时候一会去看我们去拿WRK然后去做一个nix的压测然后可以看到nix主要重点关注它的P50和P90、P99的一个RT的一个分布然后这边DEMO里面是跑了两组对 然后这个RT大概P50是152左右然后P90是在180然后P99是1毫秒左右然后我们下面是一个对照组对照组是我们会部署一个用Bass Ever Cues然后形式去部署的一个FM Pack也就是社区原生的一个混布方式然后去进行和nix进行一个混布然后我们去看nix的一个性能的变化这是第一组这个其实是压了60秒其实我们这个播放的工具然后现在会把它缩短成0秒2秒然后这个P50的RT是171大概提升了百分之就提高了百分之十几吧然后差不多然后那个P50大概170左右然后P90增长增高的明显大概提升了30%到40%然后P99也增大了20%然后其实也就是说它的RT这个常委就更明显的RT整体也升高了就军职和一个委分部都提高了然后我们可以看到现在在Bass Ever的泡的里面它的容器的CPU的实验片Cybercoata也就还有CPU shares这些还有Memory Limit的权重全是没有设置的这就是原生的混布它缺乏接点上隔离的一些情况是这样的然后混布的过程中我们前面也看到有一个整体的CPU利用率其实这个节点已经压到88%的这样一个CPU利用率其实也比较高了然后下面是进行我们实验组的一个混布Demo就是我们会这边有一个我们Cognitor的一个Couse Page的压某大概来讲就是我们开启这种前处的什么Google Identity以及前处的最不重要念的是Battery Sauce这样一个Programming然后我们下面提交一个Cognitor的BE的FM Pack它申请了我们Cognitor的Bass CPUMemory资源然后它会也在这个节点上部数起来对 叫BE MMPack然后电线都跑起来了然后这是实验组的第一组性能可以看到P950的RT就已经基本上已经比较接近Bass Line了就是是157Bass Line应该是150151左右然后P99也明显降低了然后大概在10%左右的一个相比Bass Line的差异然后P99变化到不是特别明显然后不过我们这个机器其实是一个4C的机器其实我们在更大的规格的机器上大家会容易拿到一个更好的一个混布的性能改善然后这是我们可以看到BE MMPack的POW的里面它现在它的CPU的CineCauta它的CPU shares和Memory Limit都通过我们前述Battery Sauce的机制已经配置好了然后现在这个是一个压似之后的一个数据下面可以看到那个利用率其实应该是上面那个结果就是现在混布的话利用率是75%一样我们其实还可以进一步去控制混布的水位去把这个水位进一步降低到我们比如说我们认为合理的方位比如说50%甚至65%左右然后这就是我们的一个demo部分然后我们今天的分享整体就是这样然后为大家总结一下我们今天讲的内容首先就是我们今天讲的是Connator和NR的一个Connator本身的一个资源模型的增强然后以及Cuse增强然后还有和NR的集成我们想通过这种方式也想去在原生的调度系统原生的一些资源管理系统提供一个相对优雅的一个资源管理的模式另外我们也想因为我们也知道各种各样的有商案然后相对的很多大规模企业都在做混布的技术我们也想通过我们这样一个对CubeLater和Connator Runtime都不侵入的一个技术方案然后去促进混布技术的一个标准化和规范化然后第三我们其实也通过NR和Connator集成去本身对Connator自己其实也是极大去改善它部署的灵活性我们不需要去磨改CubeLater我们也不需要在CubeLater和Connator Runtime之间有关键路径去部署一个proxy对稳定性带来额外的比较大的干扰然后同时它也改善了我们资源管理的实效性因为它在NR这个管理是对Cube管理是一个同步的我们可能遇到比如说Memory的Limiter如果一个炮的它B炮的它刚开始UZ炮的特别大我们后面再去证明Limiter可能射不上但NR这个方案是能解决的然后Connator在未来的一些工作我们这里面练了几点首先就是我们也会在后续的Connator版本里面我们先发到一二三版本然后后续也会持续去推进我们和NRI的相关的一些工作集成比如说我们会把更多NRI的特性集成到Connator里然后另外我们也会去把一些平台感知的一些Cuse能力比如说更高级的RDT能力然后去进行在Connator中进行增强包括我们前述的对缓存的管理当前是一个简单的普速的进代化分测理我们会去考虑去做动态化分以及更稀利度的一个缓存的管理然后另外就是还有我们近期在做的一个资源放大节点资源放大的一个机制这个机制其实是一个就是我们去放大节点上能调度的原生的Native的CPU和Memory资源的这样一个机制它能帮助我们去在后续的各种对在线服务的一个超卖的场景去解决一些问题比如说我们可以做CPU规划的一个调度我们可以把不同机型的一个型号屏蔽然后去做一个CPU的一个超卖然后我们本身调度上我们也有很多规划的一些点然后这边列出来比如说我们会继续去做脱补感知和QS感知的一些增强的调度然后另外就是我们会持续去增强我们在EGO设备管理和GPU管理的一些资源管理能力还有就对大规模的一些调度场景我们知道我们其实内部已经做过的我们现在会持续往开源去反馈的一个能力叫做等下类调度其实也去改善我们一个调度的性能整体就是这样然后最终最后这是我和张康同学的联系方式以及Codinter相关的一些材料然后欢迎大家如果关注Codinter的话欢迎大家去扫右下角这个这个钉钉的那个二维码其实是一个我们Codinter的一个社区的钉群欢迎大家在群里面去提问然后上面也有Codinter里面各种领域以及英特尔同学然后去一块给大家去答疑去解答问题OK就可以看哪位同学有一些问题吗是这样就我问一下就是我们现在的话我们集群的话里面是用的是蚂蚁的那个咖啡的控制器这个控制器的话可以被那个就是就这个组件可以就是去做它的QoS的一些那个吗它对它对控制器有什么要有是标准KBS自带的还是说它这么定制化的也可以去我想进一步确认就是这个控制器它具体做什么呢就在你们的场景下它是就是它KBS模样是deployment的嘛然后我们它就是蚂蚁这套的话它是它主要是是替代的deployment是做的Cover Deployment就是我们的所有的应用炮的全部是是部署在这个上面的我觉得这个肯定是就是对Connector肯定是适配的因为Connector其实它目前还没有关注到具体到那个就特别是我们在几点管理和混沌这些场景下我们其实关注最终是炮的这样一个对象炮的前面是吧对 你其实提的应该都是WallClo的相关的一些管理然后这一层其实对我们相当于说透明的透明的是吧那我问一下就是那如果说我们现在对一忧的集群去做它的那个就是QS的经济化管理的话有一些新的经验吗我分享一下整体上就是先我们得就是其实说白了就是我们做这些QS管理我们首先得知道业务自己的特征那就是首先我们要看到那个有应用的画像是吧就是对 也不一定要做成一个特别量化的一些画像就是我们整体要知道业务有哪些特点比如说我们集群上都是大树域的作业那可能是另一种管理的方式我们前述的今天主要讲的是混沌在离线混沌就是说我们把那些微服务也有还一些在线的一些比如WIFE Server这些微服业也有和大树域去做一起混沌但有的场景也可能是比如说它只有大树那个在线服务的自己部署独占的部署也或者大树的独占部署这些特征需要先确定一下然后我们再去规划具体我们是用哪些QS的设定我们去怎么做自研调度行 好 谢谢是那个后面好像一位我想请问一下就是刚刚那个demo的最后就是我理解因为Andrex的服务一下打进来有很多流量所以那个时候能够分配给BatchJob Port的资源就变少了然后就能保持最后它的延迟依然保持在150毫秒左右那如果这个时候就是这个节点上可以分配给BatchJob Port的资源以及小于它的Request值那这个BatchJob Port会被从这个节点上驱逐出去吗实际对 是我们是支持这种能力的但是BatchJob是不是要驱逐这个事实际上看这个作业它自己就希望是怎么样就是因为我们除了驱逐我们还有对CPU贼员来讲我们还有压制能力就是我们可以让这个比如说它这个BatchJob它可能它不想被驱逐它想保活那我们可以把它的CPU压得比较小让它也对那个在线业务有比较小的干扰然后这时候它是能保活的因为有些比如说它特别是像AN的那种训练作业它可能它在几个节点上被驱逐然后再跑到另一个节点上的一个代价是非常大的因为它可能比如说跑了几个小时然后你先把它驱逐了它在另一个节点又重新开始跑几个小时然后这种情况它可能会切割保护然后当然驱逐你刚说的我们也是支持的我们可以去我们现在已经支持的根据节点上实际就是适合Batch的那部分资源也就是我们那个Capacity那部分然后它有多少如果这个比例满足度特别低的话我们会把这个BPUT去驱逐掉这也是支持的是一个可选择案好 谢谢OK 大家谢谢不好意思那个时间好像已经到了然后大家如果有其他的一些问题欢迎大家去扫那个叮叮曲然后就在群里面提问我们也会在群里面去给大家解答感谢大家