这个Track主要是介绍那个Seq Scheduling相关的一些基本的介绍以及其实Qubicon在过去几年其实都没有在中国举办然后Seq Scheduling其实也没有机会和大家能够有一些接触所以我们把过去几个release里边比较重要的一些更新都加入到这一次的分享里边了首先我们两个简单先自我介绍一下我先介绍一下我是王庆参过去几年一直都在这个Seq Scheduling里边去做一些维护和开发的工作然后目前是在Shope里边去从事机器学习平台和AI Info的一些工作和建设大家好大家好 我叫英娜然后目前也是在Dalclaw的做KBS平台这一块的一个开发然后也是AI这一块方向然后的话我也是在上游做一些贡献然后也主要是Seq Scheduling这一块我们今天的主要是介绍因为Seq Scheduling其实它是分为两趴第一趴就是上游的Kubi Scheduler的开发和维护另外一趴就是还建设了关于调度指令域的一些子项目的一些维护和开发所以我们主要是分为两趴去做进展的更新首先考虑到可能有些听众对调度的一些基本的内容可能不太熟悉所以我们先对这个背景进行一个简单的介绍其实在KBS里面调动器其实做一个比较简单的事情就相当于我们有许多带调度的POD以及有一组资源然后我们如何把POD和这部分资源进行一个match其实就是调度所做的事情然后其实整个调度过程中其实分为两步第一步就是Filter的一个过程相当于我在我们所选择就可调度的节点资源里边去选择一些可以满足我当前一些对资源硬性条件的一组节点另外一步就是进行一个打分相当于我们对这些节点进行选择出来之后我们根据一些打分的策略然后选择一个最优的节点过我们整体的一个调度然后左边这个图其实是可以比较清晰地表达整个调度的过程首先其实调度器它主要是维护两部分的catch的内容一部分就是我们这个集群里边还没有被调度的POD这部分POD的特点就是它没有这个notename然后它会被调度器说握起来然后把它放到一个内存的scheduling的q里面然后供调度另外一部分就是它会维护整个集群的一个资源仕途就包括我的集群那个节点的资源以及当前正在运行的POD然后它会维护到catch里面然后接下来它会在schedulingq里面根据一些优先级或者一些排队的策略然后选择出当前最应该去被调度的POD然后进行一个调度如果它被调度成功的话它会去靠APM server的band的APM完成这个band的操作就相当于把我要调度的notenamepatch到POD的spec里面然后对应这个note上面运行的cruelite然后它会握起到这个事件从而在这个节点上去启动对应的POD如果当前调度失败的话如果你catch了抢占它会去尝试在集群里面去抢占优先级比我当前带调度的POD比较低的POD然后去控制资源然后如果没有catch的话它就会自动回到schedulingq里面大概整体的流程是这样子然后下面就是一个比较简单的例子相当于我在集群里面有N个节点然后在filter测量里面我对包括资源的请求和一些清合性一些note selector一些限制然后我可能只会选择出note2到note4的三个节点然后接下来会对这个每个节点进行一个打分然后这三个节点会根据一些清合性的包括一些打分的测源例如就是像如果我们选择了binpack或者一些spread的一些策略以及image就是观察节点是不是有对这个镜像还有volume相关的东西它会去选择一个最优的节点就类似于像note3它会是就打90分的话它就会把note3当成我当前的一个选择的一个调度节点上面就整体对简单介绍一下这个调度其实在做什么事情然后下面的话我们会去更新一下从1.25以来一些最新的一些更新首先是scheduling的plugin它其实解决了一个场景大家如果有一些比较大规模的经验的话大家会发现一个问题就是如果集群中有很多没有办法被满足调度的pod在调度器里面的话它其实会长期占据调度的资源就相当于我集群里面可能有上千个pod它资源不到但它在调度器里面会不断地尝试去重新调度这时候如果我提交了一个pod它当前的集群资源是可以满足它的话这时候它可能还需要在排队等待其他的pod调度失败之后我才能去调度这样的话其实是严重影响我们当前调度的吞吐的另外一个就是我们很多时候是希望能够控制在调度器里面的pod是否能够被调度以及调度顺序的能力的但之前的话其实我们很难去控制要么就是我们需要去写一个可能其他的pre-filter的一个插件让它先出队进入到调度过程中然后我们先让它失败掉然后再让它重新回对这种方式其实消耗了整个调度的一个计算力的所以基于这个问题然后社区上有在现有的scanner for remote里面去增加了pre-incode in-cure的extension point来去帮助大家能够提供一个扩展点来去限制是否判断pod能不能进入到实际的调度过程中基于这个扩展点就实现了scheduling gate的pulling这个pulling其实比较简单就相当于我们在pod的spec里面增加了一个scheduling gate的一个字段如果你当前是不希望pod被调度的话你可以通过增加一个外铺格的形式在这个地方把它付某一个k值这样调度区区做检测的时候发现有一个k值的话它就会直接就重新回到调度对列里面而不会进入到scheduling circle里面去进行个调度判断这样的话其实是能够比较有效地控制我们pod是否被调度的流程这个k值是可以被外部的operator去管理和控制的这样在我们一个比较复杂的一个集群里面如果我们可能有一些多调度器或者有一些更细利的一个dynamated quota的一个控制的话其实是提供了一个很大的便利的然后接下来是inna同样去好 感谢Alex然后下面的话还是framework里面的一个更新其实是我们上个rules 1.28的一个更新这是一个break change就是对incue extension的一个更新就是如果大家写过schedulplugin的话应该知道就是我们的plugin都可以去注册一些events那这些events是做什么的就是它可以让一些原本调度失败的pod然后可能会变成调度成功的这样一个事件举个例子比如说一个pod因为节点资源不够导致它调度失败了这个时候集群新增节点这个事件是可能会让这个pod调度成功的那通过把这些events注册给couple schedule它可以在从调度的过程中做到更好的一个控制比如说下选说哪些pod可以进行从调度哪些不可以从调度所以我们先看一下原来的话schedul从调度的整个逻辑就首先我们plugin会注册对incue的events到schedulq然后schedulq会去监听所有的一些APIevents然后当它触发这个从调度逻辑之后它会去便利整个我们说schedulpods这样一个pod列表然后对每一个pod进行一个events的匹配如果这个events的匹配成功之后我们就会走到下一步到一个backing off的一个阶段那backing off的话它其实是一个调度失败的pod在schedul里面一个等待时间那为什么要有这个时间呢因为我们可以想一个例子假设一些高优先级的pod它调度失败如果它没有这个等待时间它会不断的不断的重新调度导致这个队列被阻塞住所以我们引入这个backing off的一个时间那如果这个pod它的backing off时间到达之后那它就会进入到这个我们说是active queue然后它会进行一个从调度如果它没有的话它就会回到原来这个等待的一个队列里面那这是原来的一个逻辑那它有一个什么问题呢就是它总体来说还是更比较粗放的举个例子比如说一个pod因为node affinity这个plugin被拒绝之后那它被拒绝的原因肯定可能就是说这个node缺少一些level嘛但是这个node比如说这个pod需要的level是A帽号B但是这个node增加的level是A帽号C这个是没法让这个pod叫做成功的那以前的这个schedule是无法做到这一点它是没法share出来的那现在的话所以我们对这一块做了一些加强整个的一个变动其实就是在原来的interface技术上增加了一个叫我们说是一个callback的一个function那它做什么呢它就是在这里面你可以处理一系列的逻辑然后最后会返回一个hint值那如果你返回的hint叫我们说是qscape那说明说这个event对这个pod是没有任何意义的它不可能会叫做成功那所以我们就可以直接跳过这个重调度的阶段那如果它返回的是qafterbackoff那其实这是一层对原先的集群的一个兼容就是说它可能还会回到这个等待队位里面再去等待一段时间那最后如果返回的是qimmediately就代表说这个pod很大的可能性它是会调度成功的那所以我们就立马就进行这个重调度所以我们可以试想一下在集群中你去执行这样一个方式的逻辑比你走从调度一整个逻辑它性能是更好的所以这个总的设计是为了提高集群调度的一个性能所以现在一整套逻辑就是说其他其实都不变那主要是在这一块那以前的话我们是只去filter这个event那现在的话我们要去执行这个qinhint function如果当这个function返回叫qimmediately或者说它返回的是qafterbackoff但是这个backoff time已经到时间了那它就会进入到我们这个active queue然后进行一个重调度这样一个逻辑然后下面一个是关于这个下面一个是关于这个就是一个叫skip operation那比如说我们原先的逻辑就是一个pod进来之后我们会走过整个一整串比如说playfilter,filter,playscore,scoreplayband,band这样一整套逻辑但是有时候比如说这个pod它没有note affinity这些东西它其实没有必要再去走filter这个流程那所以现在你可以在playfilter里面比如说去判断说它满足某些条件那我可以直接skip掉然后就跳过这个filter阶段那其实这个也是为了提高整个schedule一个调度的一个throughput所以如果大家自己有一些plug in然后它也是分这种playfilter,filter这种有一个预置阶段然后一个执行阶段的话也是可以参考这种逻辑然后第三块是一个configure configuration就是目前的话configure configuration已经支持到了ve版本以前的ve beta2,ve beta3已经移除了所以后期大家可能都要迁移到ve上去然后整个configure API的话其实没有太大变动但是有这样一个fetch的一个过程然后下面一个是破的throughput调度一个plug in然后其实这个在我们前面几个release对它做了很多的增强那首先的话第一个是叫main domain那我们它就可以就是在你破的进行这个throughput调度的时候它可以定义你最少的这个throughput的一个数量比如说你想做一个ha的能力但是你目前节点只有目前你只有一个破的那原来的话它可能比如说你掉两个破的这两个破的是可能会同时掉入到一个节点上的其实它没有达到ha的能力但是你可以把这个通过设置这个main domain让它至少有两个domain然后它就可以通过当它发现集群只有一个破的时候它就可以通过比如说autoscalar去伸缩出一个节点然后达到两个然后就达到两个节点然后达到两个domain这样一个效果然后第二个叫node affinity policynode tense policy那其实它主要作用就是说我们以前的scheduler在算破的throughput叫做在算风的时候它其实是不会考虑这个破的是不是对节点的误点有容忍的所以这会导致一个问题就是有些破的可能会被pending住然后具体的这个原因大家可以比如说去看一下这个website和blog我们之前宣发过的就是里面有具体的一些原因那现在的话就是现在可以通过设置这两个policy然后去让破的在算风阶段可以去respect这两个policy然后第三块是match-level keys那它的作用是什么呢就是以前我们在loading updates的时候就是scheduler是无法区分它是一个新破的它是一个老破的的因为它们的比如说level都是一样的大部分level都是一样的所以通过增加这个match-level keys让scheduler有了区分新老破的这样一个能力之后它就可以当你调度完成之后你的破的还是满足这个破的top的这个约束以前的话很可能会出现就是你在loading updates之后你会发现你的破的就是没有满足这个破的top的约束然后下面的话就是目前的这个fear的整个大概是长啥样的其实就是加了三个字段一个是mendermouth一个是match-level keys还有加这两个policy下面的话是一些KBISCOOP schedule一些紫项目的更新了然后我还是乱了Alex来讲一部分我来给大家介绍一些KBISCOOP schedule一些紫项目的一些更新吧就是第一个就是COOP scheduling的scheduler plugin这个项目这个项目其实是大概两三年前是伴随着scheduler for mock的出现然后去建设出来的然后scheduler for mock的出现其实就是为了解决大家在不同的场景下对调度器有比较多的定制化的需求然后基于之前的extended的方式其实不管在性能上还是可控制的程度上其实都有些缺陷所以社区推出了scheduler for mock然后增加了大量的扩展点基本上我们每个过程都可以通过扩展点的方式来去修改scheduler的一个逻辑然后scheduler plugin这个项目其实就是把领域内的一些最佳实践的调度的策略然后聚合到一起做成一个ripple然后做一个out treat的项目来去供大家来使用然后现在scheduling plugin这个项目里面所支持的plugin的能力主要是以下这些首先第一个就是在AI和大数据里面比较重要的一个项目就是Gunscheduling这个能力今天上午一例提到的就是在OpenAI里面去做大规模的分布训练的所用的Gunscheduling其实就是这个能力然后他们在7500个节点里面通过这个方式来去训练他们的大模型然后另外一个就是capacityscheduler能力这个名字其实是跟压里面的capacityscheduling是一样的它的能力其实也是希望能够支持在不同租户之间的弹性cota的互相建议和共享来提升我们整个集群的资源利用率然后接下来第三和第四个其实是针对于节点的托付资源感知调度的一个能力的建设其实在很早之前其实k8s的couplite就已经支持了Newmark感知调度这些能力但是调度器这边其实一直只是没有跟进所以inter的同时其实就把他们对这个的想法其实放到了scannerplugin里边去做支持昨天inter那边也分享过就是怎么去能够结合调度测从集群的维度选择最好的一个托付的一个分配方式然后接下来就是基于实际节点负载的一个感知的一个调度的策略这个大家在实际的这个在线服务部署里面应该会经常遇到就是k8s调度的话它是基于资源分配的形式进行调度的它其实没有感知我节点的一个实际负载如果没有感知节点实际负载的话我很有可能把一些高负载的pods都调度到同一个节点这样导致那个节点的负载特别高然后大家性能都会下降很多所以红帽的同学就是基于需求去支持了基于实际节点负载的这个能力去提供给大家然后这些里面的plugin其实都已经广泛的应用在包括像阿里 腾讯以及包括我们shope的这个生产环境里面都使用的比较多然后这里也比较感谢就是就各位同学对这个这个插件和项目的贡献对然后目前的话我们还有两个比较好的一个场景是在这个讨论和设计过程中大家感兴趣的话可以去了解一下第一个就是基于这个节点的discal的一个感知的一个调度能力然后我们感知不同节点的这个disc的一个情况来选择一个最优的节点供大家来去使用第二个就是一个result policyresult policy 听看这个名字其实比较抽象其实我简单概括一下它其实就是把不同的这个同一个集群里面的不同的节点划分成不同的节点池然后这样我们在调度过程中可以按照节点池的维度进行一个优先级的一个选择以及这个安比利的一个分配这样我们在这个供应上去使用的话我们就可以去优先使用这个成本比较低的像这个诶 突然想到就是弹线资源去进行一个交费然后我们到年包月的资源可以在调度优先级靠后的情况下去使用哦 反了就我们去先使用我们集群里面包年包月的资源然后如果我们不够的话我们可以选择去使用我们集群里面这个安量付费的一个资源这样从而去尽量的去降低我们在供应云上的一个资源的一个消耗这个Resultpolice其实目前在阿里云的ACK的这个调度器里面其实商业产品化已经支持了然后包括在火山引擎的这个产品里面其实也有类似的能力所以我们去和这个阿里和那个头条的同学一块去把这个项目能够放到社区里面去帮助大家能够在这个通用的场景里面去更好的去完成一个调度的一个分发这个接下来就是SigScheduling叫Schedule Plug-in的一个主要的更新第一个就是我们将这个依赖去升级到当前的1.26.7的一个版本然后把我们所有的Ctrl多轻易到Ctrl Wrong Time然后在Result Topology的这个Plug-in里面去支持这个Least Newman Notes的一个配置的策略然后另外一个还有一个是Break Change我们将这个GunScheduling里面的Protogrope的API以及Compacity Scheduling里面的Elastocorta的API按照整个社区的要求去迁移到就是就X-Gun,可以把S的这个后罪里面就符合社区的一个整体的一个要求规范然后最后一个就是我们在这个GunSchedule里面去支持了用户自定义去配置Protogrope Backoff的一个时间这个能力其实可以帮助我们解决如果我们训练的作业特别大的情况下它有可能在GunScheduling里面会阻塞其他作业调度的一个情况这样我们就可以设置比较大的一个Backoff的时间让它能够长时间的等待它所需要的一个资源然后接下来介绍的是一个就是CxN6里面一个相对比较时间比较久的一个项目就是Discadular但这个项目其实一直还都比较活跃Discadular用一个比较简单的一句话去介绍它其实是通过驱逐的方式来去Protogrope能够调度到更好的极链上以实现对整个Cluster资源的一个Rebalance的一个操作Discadular其实它的场景是分为两个部分的一个是Discadule另外一个是BalanceDiscadular的话其实里面就是这个名字其实就比较好理解相当于我们最开始会在调度过程中会对Pold设置Finnity或者Tense以及这些操作然后后面这个节点可能会发生变化但发生变化之后没有一个角色不过我们重新去驱逐来重新调度Discadular现在就会去做这件事情另外一个就是BalanceBalance的情况下其实大家应该比较可以理解就相当于我们在做像AI训练里的人的话就是大家都会倾向于我们能够减少资源碎片然后通过BIMPAC的方式能把Pold堆叠到一起但是因为可能不同的胶部的运行时间不一样这样的话我们集群里面就会出现一些很多碎片的情况这样的话可以通过Discadular的方式来去做整体的一个碎片整理这是当前Discadular一边支持的一些能力但是实际上我们对资源碎片整理或者Discadular的需求其实还是比较多的就包括像我之前会针对GPU利用率的方式来去做从调度的一个编排但是之前的Discadular我们需要就是写一个从头到尾把这个策略在一个文件里面描述清楚之后把这个函数其中函数注册到这个魅函数里面其实对所有人来说扩展的成本会比较大针对这个问题Discadular它推出了就基于受到Scare Framework的影响它也提供了一个Discadular的framework的一个能力首先它提供了比较多的扩展点来去支持用户基于扩展点的方式来去实现它在Discadular上面的一些需求同时它也支持Multiprofile的一个能力这样的话我们可以通过Multiprofile的方式来去对整个机群里面在不同的Name Space或者打不同的Label的方式使得这些Polder可以在Discadular运行过程中走不同的一个从调度的逻辑而从而实现一些比较精细化的一个控制然后Discadular近期的一些比较多的更新就是它首先把所有的Plugin都从购完去再支持Discadular的framework的能力第二个就是它支持了Discadular的Profile就像刚才介绍的然后第三个就是Invabel的Open Telemetry的Tracing还有一个小的功能点就是在Node Utilization里面去支持了Name Space的Filter的能力大概就是这些还有一个比较好玩的一个项目就是Kubi Scheduler Simulator的这个项目就我们在平常如果大家去排查调度器就是经常会遇到一个问题就是我一个Polder我本来以为它可能会调度到几点A但它莫名其妙地调度到几点B但是这样的因为调度器的整个过程它特别是打分的测量其实还比较复杂就是我们去理解这个流程就会比较繁琐就是我们只能通过打一些日治然后一点点的去分析到底为什么它做的这个调度决策然后另外一个就是如果我们自己去开发调度器的调度策略然后我们也不太确定它跟其他的调度策略之间是怎么影响整个调度过程的所以社区同学做了一个叫Scheduler Simulator的一个能力它其实就是一个比较简单的模拟器的工作就是大家可以启动这个项目之后在可实化的界面里面然后通过选择不同的POD和接链的一个组合来完成整体的一个调度然后右边的话它会把这个调度过程中的每一个field的一个结果以及每个scout里面打的分数都打印出来这样方面我们大家去熟悉和排查我们整个调度逻辑对然后接下来是Ena去介绍后面的一个项目我看下面其实有些同学上午已经听过这个相关的项目了但是麻烦大家再听一下然后这个第一个项目是其实是去年开源的但是对国内来说可能是一个新项目叫Q然后目前的话它主要是做job的一个管理然后它提供一些能力比如说像刚才说的job的管理然后它提过很多的这个陆列策略像5-4 Best Effort然后的话它支持这个多速户然后就是它另外的话第三块就是说它可以支持对资源配额的管理然后配额之间做一个fair sharing第四个的话就是一个资源可替代性就是很多时候我们比如说在训练AI任务的时候或者说做一些训练一些跑一些作业的时候可能本身是有GPU的但是用CPU也行就是说慢一点所以它可以提供这样一个资源的可替代性它做了一层抽象然后最后一个是这个两阶段提交就是Q在Q里面提交一个所以它分两个阶段第一个阶段就是说它本身会去通过自己的一些逻辑判断说这个主要本能不能运行然后第二个能力就是它把这个adminshadminsh的这个能力开放给了其他第三方比如说一些用户可能在用公有营是吧它有一些8G尺的预算那如果当你超过这个8G尺的时候你就不能再申请公有营资源了所以它把这个接口也开放出来了这样子用户可以说可以揭露自己的一些系统总的来说就是Q它主要是解决这个在KBIS层面就是如何去管理job的这样一个能力然后它就是我们我们应该如果大家对schedule比较了解的话在这个市面上现在有很多的调度器比如说具体是哪些调度器我就不说了就是他们可能会也融入这个Q运的能力但是Q的话它的整个的一个设计原则就是说它需要做到这个关注点分离比如说现在KBIS一些核心组建像couple schedulercouple controller manager还有classed auto scheduler他们的能力Q不会去做但是Q要和他们做一个五分的集成是这样一个设计的原则所以它现在是一个独立的组建可以进行部署然后开发所以眼睛也会比较快一点然后Q怎么去工作的然后我也简单地说一下其实主要是分成两个阶段一个是我们说是叫Q运一个是schedulingQ运的话就是说主要是这一款就是所有的job提交到Q这个系统之后Q就会进行一个接管然后去根据一些quota来判断说这个job能不能在集群里面运行如果这个job一旦能够在集群里面运行然后第二阶段就是到了scheduling阶段就是跟我们平时的调度逻辑很相像就是job会去创建podpod会进行一个调度然后最后的话如果pod本身集群资源不够的话它可能会panning住这个时候autoscallow就会去伸缩一些节点然后满足整个调度的需求大概就是一整个调度的逻辑然后目前的话刚才说到Q他作为一个独立的项目去远近的话他迭代会比较快所以现在他支持了很多的job然后标览的是一些已经集群的然后标灰色的是正在进行中的从上至下像kubernetes生态的话第一个是他原生支持的这种batch job第二是他现在已经支持的jobsetjobset是一个什么项目呢我们如果跑AI job应该知道是现在有很多的类型的AI job像pytorch,tensorflow,然后像mpi然后是要touch boost等等然后他每个job都需要有一个对应的operator进行管理原因是因为就是他们的API都不太一样然后特性也不太一样那jobset他做的事情就是说我把这些东西都抽象成了一个API这样子我就不需要说我去跑四个operator是吧我一个就把你们全搞定了是这样一个事情然后后面的话我们也在考虑说集成这个pod然后第二个生态就是他对rejob有集成然后今天上午其实我也跟自己的朋友同学分享了一个关于q和kubernetes去管理rejob的一个session改进去的也可以只能可以看一下到时候应该是有youtube的视频第三话就是kuberneteskubernetes基本上目前大部分的job都已经支持了然后非常感谢kubernetes的社区的一些贡献人员然后最后的话就是如果你有自己的一些job你有一些自己定制化的job你也可以指路到q的一个系统其实你只要去实现一些我们定义好的job framework然后一旦实现了这些formwork之后你就可以很轻松的创建自己的一个operator然后下面的话就是我们简单的应该是在一个月左右吧我们会发布我们的0.5.0版本然后0.5.0版本的话会包含几个能力其实刚才已经有介绍到了那第一个的话就是它引入了更多的metrics然后在可观测试这一块可以有个提升那第二个是它引入workloaded priority就是现在有些情况就是有些job它可能在这个集讯里面会运行很长的时间就导致其他的job被饿死就是它没有自愿去运行因为这个job把所有自愿都吃掉了然后这个时候通过workloaded priority把这些deo的job把它升级然后让它提前去运行然后让它得到一个公平调出的机会第三块就是刚才说的我们目前已经支持的大部分的couple flow的job然后第四块就是我们也会再考虑说支持podpod的一个编排然后第五个就是刚才说到的这个两阶段提交这样一个事情给让第三方的系统也可以揭露到couple的这个决策逻辑里面来然后最后的话就是我们也在集成更多的这种抢占的一些策略然后更加高级的这种抢占策略的支持然后最后的话就是我们目前也发起了一个adopt list就是如果大家再用couple的话也可以填一下adopt list然后给我们一些反馈就像我刚才说今天上午其实我们有做过一个关于用couple和couple如何去管理工作负载的这样一个分享然后大家感兴趣可以看一下下面一个项目叫coc然后如果大家有关注国内比如说像CNCF的这些公众号应该对这个项目了解过其实它总的来说就是一个管理集群的这样一个工具它可以很方便地创建一个超大的一个集群所以它提供了两个工具一个叫coc它本身就是说用来去fake一些节点fake一些pod然后或者说其他的API资源那coc control的话大家可以把它想象成是一个看着的一个CLI的工具它可以用来去比如说创建啊删除集群总的来说coc它这个coc很火它现在已经快有2000个star了它主要是因为它首先是比较轻量就是你可以比如说你用一台笔记本你可以维护1000个节点还有10万个pod因为它们本质上它们其实都是一些API对象那第二个它创建起来很快你可以比如说每秒可以创建几十个pod几十个node然后的话它是非常的灵活因为你比如说你这个pod和node它是有节点状态有这个pod的状态的你可以通过coc去模拟它任何的状态然后去fake一种情况我才要把你想要怎么样就可以fake成什么样子然后最近的一个临利斯的话coc就是首先它做了一些更新吧首先就是以前的话可能现在它可以支持通过CID的方式来对coc的配置进行更新然后第二块第二块是它现在已经支持的couponadisdashboardcouponadis官方的一个项目第三个就是它现在对这个已经做了集成然后可以做一些tracing相关的事情然后第四个就是常见的这种性能这一块提升的一些工作以及它其实有很多的小的feature都实现了但是我可能这边没有全部列出来然后其实昨天昨天我刷这个社交的时候也看到就是k8s的项目叫e2u framework也刚刚集成了coce2u framework就是用来k8s用来做e2u测试的这样一个框架它从过集成coc来达到这种一个是更快另外一个是更省这样一个能力然后如果大家我这边介绍的是很简单的如果大家对这个项目很感兴趣其实明天下午这个有一个专门的一个关于coc的分享然后其实我们的这个我们的founder其实也在下面听着市民同学然后下面还是一个比较新的项目叫coc schedule with some extension我们以前怎么去扩展我们的scheduler呢其实我们一般是三种方式嘛一种是framewalk就是我们自己可能会去写一些paragay的方式然后去重新编译做一个定制化的framewalk第二就是我们可能会在集区里面搞这种多调度器的这种方式对然后第三个就是我们可能会用一些extender就是webhook的方式来去集成这个我们现在的scheduler但是他们都有一些问题比如说第一个framewalk那它的话它就需要你你去重新编译这个framewalk还有一些情况就是比如说你在你做一个平台然后客户他有自己的paragay那其实你是没办法把客户的paragay放到你自己平台里面来的因为客户他不想把你的弹码就是暴露给你这个时候就很难办第二个是多调度器那首先最明显的就是说资源会有一个损耗多个调度器肯定是对几群资源是有消耗的另外一个问题就是说多调度器的问题就是你同时有两个调度器同时在调度的时候他们因为调度器在调度的第一阶段他会做一个snap shop然后这个时候他们彼此是不敢支的所以很容易造成我们两个调度器同时都调度成功了但是最终可能因为资源不够只有一个port能够调度成功然后另外一个可能会被cubelet给驱逐掉了所以他也会有一个调度冲突的这样的问题ex tender的话他的问题就是说他延迟会比较明显然后其实cubelet的上游社区也在考虑说也其实也慢慢的在希望用户能够牵引到framewalk而不是说ex tender所以上游的这些feature什么的可能也不会再维护太多了那有没有其他选项那肯定是有的就是我们的标题就是web assembly然后其实在其他项目里面比如说像East2像envoy像deafat他们其实都有这一块的集成的案例然后我这边就简单的介绍一下他是怎么工作的就是首先我们在这个scheduleschedule这一策我们会集成一个wasunplugging这个plugging是上游社区已经写好了然后的话你要做的就是基于这个项目定义好的这些interface然后去写实现自己的方法然后你可以用任何语言去实现你实现完之后你把它编译成一个wasum文件然后这个wasum文件会通过一个路径的方式直入到这个wasunplugging里面去这样子就完成了整个集成的过程然后它是可以动态插拔的就是你可以动态的去编译然后动态的直入你不需要重新去编译整个加入器然后这个时候呢就是然后调度逻辑是其实是没有任何改变的就是schedule还是会去调比如说去调field那这个wasumplugging就会去调这个gest的一个这个运行时的一个方法然后我们的话因为现在wasum很火然后它有很多的round time然后我们选择的是wao zero因为wao zero是唯一一个不用sego的这样一个round time因为就是sego的round time目前k8s社区是不是很认可因为k8s社区主要是购物语言来去实现的然后语言的话目前用是tinygo因为用go来去编译这个wasum它文件会比较大所以我们用tinygo来去做这个事情然后虽然有一些功能可能实现不了但是基本上问题不是很大然后大家如果想要看一些example的话这边也有一些example然后下面一步的话就是其实这个项目目前还在开发中如果大家感兴趣可以去参与这个项目的开发然后未来的话比如说首先第一步我们可能会去支持所有的extension points因为现在的话只支持了这四个然后第二块是性能的提升其实大家可能也会很关注这一块像wasum这个项目目前的话是差不多两倍的延迟当然这个我们可能需要更多的编曲码测试来去覆盖但相比于比如说像用extender那我们测试下extender可能有十倍左右的延迟所以它其实是已经是更快了然后第三块就是我们会去考虑说支持更多的pod和node等除了pod和node之外的一些资源然后最后一个就是因为其实wasum它支持任何语言所以我们现在需要提供一些其他语言的一些example然后也是非常感谢参与这个项目的开发认为尤其是来自于waziel的Angel就是这位然后他贡献了很多的idea和代码好 其实今天主要的都差不多讲完了然后大家如果想加入Kumneri的社区或想加入Skeling社区的话如果你是比如说可以从一些简单的e-shoot入手或者说如果你有些疑问的话可以加入我们的slack做一些交流我们的话也会有一些这个周期性的meeting然后像国内的话可能每周 每个月第一个礼拜四我们会有这个apak meeting大概是早晨十点然后社区也提供了很多的像文档比如说caps还有设计文档以及社区参与的一些规范对 然后这就是今天我们主要讲的内容然后时间也差不多了然后可以对大家有什么问题吗discaler可以帮助你就是这样的discaler就看你的配置策略了如果你是想打散的话discaler会去计算这个节点里边是不是有一些更好打散你这些服务的一个选择然后它就会把你当前正在运行的就是比较满了那个节点的部分的pod进行一个驱逐然后经过调度区的一个重新调度就会把这些pod放到你新加入的这些节点上去对因为其实我们相当于在调度过程中schcaler其实是负责单次性的调度它就会至于当前的资源速度做一次性的调度然后另外discaler就会去负责帮它就是因为它过了一段时间资源速度发生变化了它会负责帮它去可能通过驱逐的方式然后去更好了再去让它重新调度一次然后补充一下就是你需要承担的风险就是说这个pod会被evictile就是它会被驱逐掉所以你就要保证HA不然的话有可能会service unavailable这个你需要自己去配置一些具体的它的eviction其实就是pdb的就看大家还有什么其他问题欢迎你好我再问KQ的问题我刚刚之前没注意到好像是计划支持rawpod就是直接pod的admission这类的一些这个admission就是介绍于刚刚另外一位同学提到了skidledin gate来做还是他怎么他网泼的时候怎么去做admission就是不让他调度还没定是吧这块有什么现在有什么买店吗是会改pod的epn吗有个意思你可以看KEP的设计现在还在review去了对那就到这里好 谢谢大家祝大家中设计愉快