《原动力 x 云原生正发声 降本增效大讲堂》第六讲——Kubernetes资源拓扑感知调度原创

各位网友大家好，欢迎观看原动力云原生正发生降本增效大讲堂系列技术直播第二期的最后一场直播。来那第二期聚焦全场景在离线混Co GPU资源效率提升、Co资源拓扑感知调度主题。原动力云原生正发生降本增效大讲堂是由中国信通院、腾讯云奥产业标准工作组联合策划，目的是与开发者一同交流提升资源利用率，降本增效的方法与优秀实践。那我们在6月23号，还有6月30号，还有7月7号呢进行了第一期的直播，那我们第一期直播的主题分别是云原生降本增效优秀时间案例分享。Co云上资源的分析与优化，Co集群利用率提升实践，在7月28号，还有8月4号以及今天晚上的8月11号，我们将进行第二期的直播，那直播主题分别是kles全场景在离线混部。

通过云原生管理GPU资源、Co资源、拓扑感知调度，那欢迎大家观看回放，点击当前直播间下方的往期直播按钮呢，或者进入活动专题页面即可进行观看和学习。今晚呢，是该大讲堂的第六讲，直播主题是苦ned资源拓扑感知调度啊，我们邀请到腾讯星辰算力平台高级工程师方锐为我们分享资源拓扑感知调度。在观看直播过程当中，如果有问题呢，可以发送弹幕进行提问与互动，那我下面我们有请方锐老师。各位观众朋友们，大家好，欢迎大家来到原动力云烟深圳发生降本增效大讲堂，我是今天的讲师方锐。我来自腾讯TG基础架构部，一直从事腾讯内部最大的离线计算平台新算力平台的研发工作，那么我也是一直专注于离线计算与大规模集群调度这个方向，接下来呢，由我为大家开始今天的课程讲解。

今天我为大家带来的课程题目是资源拓扑感知调度。那么在过去的几年内，相信很多企业都是通过嗯，自研上云或者容器化改造的方式，推动传统的应用进行容器化的迁移和改造，那么通过KS的方式去托管这些应用，那么可以实现一个很好的降本增效的一个效果，呃，那么随着业务的不断发展，我们会发现在。呃，大规模的一些离线计算场景下。通过传统的cos的。呃，使用方式呢，已经达到了一个降本增效的一个瓶颈，那有的时候我们需要在这个调度方面去做一些更加精细化的。

工作，然后来去实现这个降本增效的一个效果啊，我们今天这个课程呢，也是更偏向于增效这个方向。因为在离线计算中。可能。应用和应用之间，因为本身应用的利用率会比较高，它应用跟应用之间会有比较强的一些干扰，那么我们会通过更精细化的调度来去实现增效的结果，避免避免应用与应用之间的一个相互的一个竞争。呃，首先为大家简要介绍一下我们这里的业务场景，腾讯新算力平台是腾讯内部。的离线计算平台，那么它主要是服务了有呃，王者荣耀，腾讯广告，腾讯视频。呃，腾讯自动驾驶，腾讯地图看点啊，优图啊等等等等这些上层大家可能比较熟悉的一些应用，那实际上这些应用它是偏离线与线为主的一些应用。它主要会涵盖三个方面啊，一是机器学习任务，第二个是一些大数据的任务，最后是一些多媒体计算的任务，多媒体计算任务主要会包含。

呃，视频编码，解码等等这些内容，那么我们腾讯新城算力平台底层是依托了CPU算力，GPU算力，还有一些易的fga类的一些，呃，五花八门的算在里面，那我们需要去为业务去提供一个稳定的计算平台。同时我们需要的算。然后屏蔽一些。呃。不稳定性的资源，然后使得整个整个离线计算更加可靠，那我们在这个整个运营的过程中，我们会发现离线计算具有一些利用率比较高的场景，我们就需要去呃让各个业务在使用容器化的方案的时候。避免相互之间去产生竞争。那么今天。我会，呃，我的主题是Co资源拓扑感知调度，我会从以下五个方面来为大家进行一些介绍，那么首先我会介绍这个资源的竞争与资源感知的问题。

然后紧接着我会呃来到库精细化调度这一块，精细化调度去。嗯，通过扩展调度器的方式去解决这样的一个资源感知问题，那么接下来我们会来到容器的CPU的管理，那么在调度完成之后如何去实时的。呃，去执行这些调度工作，那么会，呃，避免容器之间的竞争，我们会来到容器Cpu管理这一节，那么最后就是。在离线场景下的实践啊，在离线场景也是一个降本增效非常有效的一个。方案，那么我们的拓扑感知调度会去配合在离线混场景来实现一个更加精细化的资源分配，最后我们会总结今天的一个课程。呃。首先的话，我为大家来介绍一下资源竞争与资源感知问题。首先我们为大家介绍一下CPU的这个体系结构，嗯，现代CPU多采用牛马的架构的方式，牛马架构是一种非对称的这种结构啊。

每个note上它会有自己的物理CPU，然后每个note去共享L3。然后同时这个呃，内存它也是分布在每个new note上的。那有一些开启了超线程的CPU的话，它一个物理CPU和在操作系统上会看到是有两个逻辑的在里面。那么这些CPU核心，它实际上是分布在各个new note上。那么new它本身就会有一些新核心的元素在里面，我们可以从右图中可以看到。CPU cash的访问速度是不一样的。如果我们的程序都跑在同一个new note上，我们。我们去可以更好的去共享这些L3开始，那L3开始的访问速度会很快，如果我们L3开始。

没有命中，我们去到内存中去读取数据的话，那我们的这个缓存速度会。大大的降低，然后大概是差了一个。数量这样的一个情况，呃，所以从这个CP体系中我们可以看到，如果我们采一些C方式分配方式。就会成为呃进程。在离线计算这样过程中的一个性能瓶颈，然后严重去影响应用程序的性能，所以在这样的一个体系结构下，我们就希望容器与一个容器，它可能尽可能去利用这样的一个cash的特性在里面啊。去遵循CPU体系结构的特征，然后去防止应用程序速度急剧下降。呃。在这样的一个体系结构下呢，就会存在云计算中特别常见的一个吵闹的邻居问题。

肠道的邻居，问题是，呃，当多个容器在节点上共同运行的时候，那么它由于资源分配的不合理的一些方式，那么会对。会对城市本身的性能造成一些影响。首先我们看一下理想的这种使用方式，如果呃，这个机器上有两个new node，然后newman node0是。呃，理想的方式是把它完全分配给这种进程零，然后进程一呢，完全使用六一上的四个核心，那这样子。呃，在理想的这种方式下，每个进程都各自使用自己的CPU和，然后不会跨马去访问，那么这样子它的程序一直在跑，那L3开始的就是命中率会很高。然后同时。呃，他。他们相互之间就会不会有太多的争抢来去造成这种频繁的上下文切换。那么在一个糟糕的使用方式下，我们可能会。把两个进程的CPU核心去。呃，分配的没有遵循这种new的亲和性去做分配，那么这个时候就会，呃，带来很大的一个性能问题，那这个性能问题主要是有这个三个方面吧，第一个就是CPU的增强，带来频繁的上下文切换。

我们知道CPU，呃，我们知道进程在运行的过程中，它在。嗯，操系统会去不断的调度这些进程，如果我们去做一些糟糕的使用方式的话，那么CPU在切换这个时间片的时候，它需要去做一些呃，双下文切换的工作。那不同的进程如果在。频繁的去这个CP的话，那么在这个过程中下切换会带来的一些耗时间。那么第二个就是如果我们去做这种频繁的进程切换的话，那会导致CPU的高速缓存失效啊，高速缓存失效。我们从刚才的图中可以看到，它的时间会大大的增加，那这个时候它带来比较严重的一些性能瓶颈，那么呃，开始的命中率会降低。最后就是这种跨流存带来更严重的性能瓶颈，呃。

如果我们的我们的这个进程在newman note里上，然后它同时又去使用了newman node1上的内存，那么可能会跨newma去做一些访访问。这个时候。它的速度会更慢呢，这里，这里的性能瓶颈会更加严重，那在这个吵闹的邻居，问题是。是在这种利用率比较高的场景下，会经常遇到一些问题，就是相每个进程似乎看起来自己的CPU利用率很高，但实际上他们发生剧烈的争抢。所以其实。呃，实际上是大大浪费了CPU的算力，那这个时候我们需要去解决这样的一个道的问题。呃，接下来我们看一下K8S给出的一些数据吧。KS中。呃，有这个CPU manager这个功能，CPU manager是CU的一个组件，那么它可以去做一些CPU核心的分配工作啊，可以让。一些guarantee的去独占一些CPU核心，而不让其他的。呃，Pod去使用这部分CQ呢，达到一个独占的效果，那么左边这张图是guarantee first这两种pod的一种测试方式。

那么我们可以看到他将CPU manager的这个。这个执行时间做一个基准，然后我们可以看到，如果是。呃，原生K8的这种方式，在不同的测试case下，它的性能都会有较大的一些波动，那么最差的话可能会达到。1.8左右。呃，就是这种guaranteed和本部的方式，第二种方式就是。呃，这种主要是去抽取了一些。机器学习任务。包括re net50，还有WDC这两类的机器学习任务实际的一些测试，那么我们可以看到，其实在这个re ne50的这个场景下，如果你去做一个CPU的绑定啊和完全不做CPU绑定，然后这些进程去共享这些CPU核心它的。

执行时间差别是很大的，因为这个时候就发生了剧烈的CPU以及频繁的双切换啊，那么最差在这种情况下可能有一倍的性能差距。那在这样的一个闯荡邻居问题下，我们可以看一下KS是做了如何的解决呢？刚才这个CPU manager的方式，它就是其中的一个解决方法。这个解决方法目前嗯，是放在这个cut中。Set将会被manager分成两个池子啊，一个叫default，一个叫exclusive default就是如果。呃，如果不做绑和默认的进程都会使用。这一些这个池子啊，比如说这个系统守护进程。CU reserve的，还reserve的这种预留给KS组件，还有系统组件的这些资源。还有第二种就是。特殊特特别类型的一些port，比如说bus，还有best effort，还有这种请求非整数CPU的guaranteed，它实际上也是这些port都会使用这个default，也就是共享式。那如果我的。

机器假设有90个96个核心，那么。这个96颗星默认都是default，那么pod和系统守护进程都可以使用这96颗星。呃呃，那特别说一点，这里就是在。在这个有一些一般零号核心都是预留给系统守护进程的，所以说一般是使用剩下的，比如说这个95个核心。也是需要保证这个系统的一些守护进程去正常工作，那么呃，第二个池子是exclusive这个池，这个池子它是完全排他的一个。CPU值，呃，Pod，如果去请求了这个整数的。CPU核心，并且它的类型Q类型是的，那么他们就会被分配到这种完全独占的CPU核心上，比如说pod请求四个CPU分配到了这个，呃。

一到四这个CPU。核心，那么这一到4CPU核心只有只能由它去独占，然后其他的所有的容器都不可以去使用这些CPU核心，那么实现了一个避免肠道问题的一个效果。那它是对于这个拓扑管理器，它需要就需要满足拓扑管理器定义的一些要求，比如说它的这个核心必须在同一个new note上啊，这个是为了保证它更好的一些性能。大概是这样的一个结构。那么manager呢，也会。主要是通过这种C的方式去更改容器的set啊，C里面有一个接口叫update container resources。那么呃，Manager会在容器启动之前。把容器去去更改容器的这个，然后去去规定这些容器到底。能够运行在哪些核心上，那么它的方式是通过的set子系统去完成的。那我们来看一下原生K8S它这个局限性在哪里吧。第一个就是。

啊，这种方式它是首先调度系是不能感知到节点的资源拓的，因为调度系它本身做的一件事情就是为一个pod去选择一个合适的node。他去不关，他不关心节点的资源拓扑，他也不会把pod调到节点上，他也不会为pod去做一些资源的分配，那这个时候如果我们想做一些精细化的调度工作，调度器这里是没有办法感知到它的，它的拓扑结构。所以就没有办法做这件事情啊，比如说在调度器的视角里，他可以看到这个节点有两个点，比如说它有八个核心，那么如果请求四个核心，他有可能会把这个调到这个节点上，实际上这个节点的结构是不知的，这个节点上有两个。New曼NOTE0，可能它的零号和一号CPU已经被占用了，那么曼NOTE1上的四号和五号CU也被占用了啊，这个时候pod如果求4CPU，但是pod有非常。强烈的这个性能要求，它就是必须要分配的核心在同一个new note上去避免刚才所说的not的各种。

各种那些影响素性的那些。呃，缺陷在里，所以说这个时候其实调度器不知道节点的top结构，这个时候把炮调度上去之后po实际上不能满足它是这样的一个top的要求，那其实Q直接会。呃，去。标注这个pod生产失败，然后。呃，这个时候如果pod启动失败，你去用一些外部的控制环去部署一些po，比如说通过department去部署，或者是。由于生产失败的话。控制就会重建一个新的，这个新的。又大概率又可能又落这个节点啊，这个就会导致一个死循环。创建失败，然后重建，然后又落在这个节点上，这样的一个循环，这个时候对于这些它需要快速扩容的一些应用啊，这个时候经过这样一个死循环，它的对它的影响是比较大的那。

第二个的话就是CPU的分配策略了，刚才我们有看到C，它的分配策略实际上就是有两个职，一个是default，还有一个是exusive这种独占的方式，那它的C分配策略是比较单一的。我们实际上需要更灵活的分配策略，特别是在这种多租户的离线计算这样的一个场景下。它的S也是不一样的，那有些word可能会说，我只我就只关心我的这个CPU是不是在同一个new note上。我呢，可以忍受跟其他的去分享这些CPU核心。那么实际上它其实只关心自己的性能，而不是说去需需要独占一些CPU核心。嗯，D2它会说，呃，我就是只关心我的CPU盒，不要到处飘来飘去，就是这样子。他有可能去。上下文切换的程序。造成一些能上的影响，那么实际上是可以跟其他的共享这些C。那这种方式呢，你会看到它，因为它不占这些，呃，CPU核心，其实其实它的这个。

可能相应的一些，呃，收费啊就会更低一点，因为它它实际上是。呃，不会通过这种独占CPU的方式去完全利用这些CPU啊。它肯定也有一些丰富的效应在里面。然后POD3，它有可能是请求的整数CPU，它也是guarantee类型的，但是它实际上是可以跟其他的pod去共享这些C的，那在方式中。这个D只会被独占，CP核不能去做到的去使用共享的，这个时候我们就会发现K这个CPU分配策略过于单一了。我们我们就我们就需要去做一种灵活的方式去增强这个CPU的分配策略。这样从而达到一个啊。多种业务场景都能适配的一个情况。那我们最后我们看一下本部场景下的离线算力感知问题啊。在离线的混这种场景下，在线与离线它都会去混，用混的方式去部署在同一台主机上，那么在闲时，也就是指在线闲时的这个时间点，离线任务它就可以充分的去使用资源，来提升主机的利用率。

这样子在忙的时候，也就是在线任务。达到一个峰值的时候来离线任务呢，就可以被在线就是抢占，然后等待在线的资源做一个释放，这这个情况下，它在线离线的这个优先级是不一样的，那么离线可用的算力呢，它就会在受到这个在线的干扰而动态变化。我们都知道，在K8S中。呃，节点的资源是静态的，这个静态的资源是由cuber c cvir啊去做一些采集，然后就比如说这个节点有有多少核心，它实际上已经是定了的，那么调度器它其实感知这些节点的静态资源，那在我们这种在离线场景的场景下，我们可以看到离线可算力它是受在线的干扰而动态变化，如果。如果忙时了，这时候。

忙时，那么我们如果去调度过多的离线任务，就会导致剧烈的资源强，这个时候反而每一个的离线，它的性能都会下降。呃，这个图例也可以去形象的看出这样的一个场景就是。在线达到忙时啊，他去请求更多的CPU时间片，那么在离线的对离线这些pod他就去不能忍受了，他需要说。就跟说我不要不要调度更多的上来，离线的上来，这个时候这个节点的已经很严了，那么我们就需要在调度期，在调度的时候去动态的感知这种离线的实时算力，而不是说去采用Q的这种静态的资源。然后第二个就是。驱逐器，驱逐器它需要在在线。在线干扰离线比较严重的时候，去去比较实时的去驱逐这些离线的破，然后保持节点上算力的算，节点上算力跟请求。算力的一个相对稳定。

所以大概在这样的一个场景下，我们就会看到有资源竞争与资源感知问题，那原生K不能很好的改，呃，不能很好的解决这样的一个问题，我们就需要用这个的精细化调度方式，那接下来我会为大家介绍一下这个。的精细化调度，也就是我我们今天要讲的资源拓扑感知调度该如何去完成。首先这样的一个精细化调度系统。大概是这样的一个结构。我们。我们首先去，呃，在节点上我们开发了一个组件，这个组件叫in worker，这个worker它是一个set，嗯。刚才有说cut，它本身采集的资源是一些比较静态的内容，那么这个节点上CA worker。他会去采集拓扑相关的信息。这个托普相关的信息呢，是为调度器做决策而用的，因为此时调度器并不知道节点上具体的精细化的拓扑结构是如何，那么它采集的方式可能是。从这个杠C或者杠DV啊，还有等等一些其他目录，我们都是可以扩展这些目录下去采集到节点的。

这个。一些拓扑结构，以及这个拓扑对应上拓扑结构内对应的这个资源。嗯，这个时候他会创建这个叫NRT这个对象。他创建这个对象，就是每个节点都会有一个这样的一个NRT对象啊，它是一个CD方式创建，然后。然后我们还有一个中控组件叫in master，这个master它是从外部系统去采集一些节点的扩展信息啊，这里是。这里是可选的，可能是比如说我们现在如果不是混部场景，可能就不需要这个组件，那这个组件它是从一些。嗯，外部系统去采集，比如说跟那个呃，离线可用算力，刚才有描述到离线可用算力动态调整的这样的一个指标，动态算力到底是多少，那到这个N里面去。呃，最后就是我们调度器，我们调度器是scheduleins，它是扩展了K8S的调度器，通过这个schedule framework的方式，那么去做一些感知，相应的一些插件会放这个调度，然后调度过程中，调过程中。

他通过拿到这个NRT对象，就知道经验上的拓扑结构如何，然后通过通过po。也可以知道这个pod当前分配在哪些拓上，那么他们就可以实时的去计算出。呃，节点剩余的拓扑资源到底是怎样的，然后去做一个更加精细化的调度，那右边这个图也可以大概看一下这个结构，这个结构实际上是。这个ZS是就是描述了整个节点的每一个错误区域内的一个信信息，然后它可能比如这个节点它是只有一个的，这个马上NOTE0上是可分配资源到底是多少。然后它类型其实就是一个note啊，包括这个节点上它cut。CU的这个是否有打开啊，如果已经打开了的，我们这个组件不能去做相应的一些工作，包括这个attris这个字段，它是做一些扩展的。

嗯，我们去啊，设计成一个可扩展的一个资源，那么。嗯，比如说场景，我们就可以这种额外的特殊的这种资源去写到里面去啊。啊，这样去做一个更加好良好的一个扩展性工作。呃，也是通过这种扩展schedule framework来实现。那扩展调度器主要是分为这个。这几个插件，我们就会在这几个这几个插入点去做一些插件，然后去来来保证实现这个资源感知调度的功能。首先我们在这个filter这个插件内。呃，去去做一额外做一个节点拓补，资源过滤的工作。然后同时我们也会去选择zone，然后并分配资源，在这个filter插件内呢，我可以看到刚才那个NT对象，我们可以拿到节点的资源拓，那通过pod的已调度的一些结果，我们可以拿到这到底我们为配哪些CP啊，或者是其他的一些资拓的一个资源。

那我们其实可以实时的知道每一个节点，每一个top区域内到底还剩多少可用资源。通过这种方式呢，我们就可以拿到满足要求满足拓要求的这些note了。然后。在这些note上去。呃，具体的选择拓扑区域，然后分配资源。那在这个score阶段呢，我们就会根据Z的个数降去打分啊，这里为什么是根据Z的个数呢？因为。我们刚才知道，如果把一个全部绑定在同一个new note上，这样它的性能是很好的，那这个的个数就是体现这个过程。我们希望尽可能。不让他纽马去访问，如果实在是要跨纽马去做一些绑定的话，那我们也希望跨可能少的牛马，所以这里是一个降水打分工作。然后在这个reserve阶段，是为代绑定的节点去预留一些top资源来避免数据不一致，那这个KS中也会有这样的一个操作，因为我们在实际绑定之前，实际上啊，这个结果还没有去写到pod中。

只是我们在调度器内部需要去预留。这部分资源，防止数据不一致的现象产生，呃，一旦这个结果写真正写入到后来之后。我们就可以去在开始中删除这些资源。然后最后就是调度结果该怎么附加了，比如说去调个。多少资源，这些情况我们会写在中，我们会在之前在阶段去写进去。最后去完成这些调度工作，那我们的调度算法呢？在节点与托选择方面是这样的。刚才所说的理想方式，我们都希望。这个。绑定CPU核心。互相之间。呃，各个相之间不会干扰，那我们同时我们希去同一个比较失败方式，可能就是这种杂交错方式，大家都没有使用好CPU，那么在性能方面我们优先选择pod能绑定在DA note内的节点，那这部分节点，呃。

呃，如果。呃，如果找不到这样满足要求的节点的话，我们也会去优先选择在同一个new ma内的note，也是为了降低它存的一些成本，那么这样子的话可以达到更好的一些性能提升效果。那从这个负载均衡的角度去做考虑，我们是优先选择空闲资源更多的new。呃，因为在离线计算的场景下，实际上资源的争抢会比较激烈，所以啊，我们希望不会出现某一个节点。呃，那。嗯，某个newman note特别繁忙，然后其他new note又特别空闲的这种情况，所以我们还是优先去选择空闲资源更多的newman note。那这样的方式，我们做一个性能还负载均方面的一个考虑，从而去更好的去选择节点，择拓。

呃，接下来为大家介绍一下这个容器的CPU的管理，那刚才有提到。精细化调度，他做了一些拓扑感知方面的一些功能，那么实际上落到节点上，我们该如何去实现？这样的一个资源的分配呢，我们去在节点上就需要交给一些特定的组件去完成这样的一个工作，就是真正的调度执行。呃。我们设计的是这样的一个资源分配系统，刚才有提到调度器此时已经未破的，在调度过程中未pod，选择节点的同时还选择了节点的拓扑结构啊，你可以简单理解成每个节点上。那嗯，分配了哪些new马no，然后这个new分配多少核心，那这些工作，那么最终执行呢，还是需要去节点上做一些执行工作。那我们的这个刚才有提到去收集拓扑信息的卡worker。此时。

此时去做了一些。额外的一个切换，额外的一个角色，他就是变成了一个执行者。他会去真正的调用容器运行时接口，完成容器的CPU绑定工作。那首先呢，这个时候如果调度器已经调度了pod，嗯，节点的bert首先会监听到po的。Pod生产出来，然后并且调度完成，然后就开始准备启动这个pod节点的，他就去调容器运行接口来去启动这个容器，那与此同时。我们的这个节点的卡ER，它它通过类似QT10250这个HTV的端口来去获得。这个节点上运行所有泡的。那从这个pod中，Pod中我们就可以拿到调度器额外做的拓扑分配的这个结果。做，那它根据这个结果去调用容器运行时接口来更改容器的这个饱和结果。那么就是通过刚才前面有提到的那个update container resources那个接口啊，为什么要这么设计呢？因为首先我们是不想去改变客的源码，这样子如果改变了，那对以后的K升级也是一个比较麻烦的工作。第二个我们这个饱和它其实异步进行。

他没有说是。Watch port，这个是因为在实际运行过程中，呃，我们会发现大规模的集群节点上set watch会。会产生一个对A会产生一个很大的压力，特别是这些DN需要升级啊，重啊之类的一些工作的时候，那它类似节点的这个10250端口也是为了去。S。拿到这个结果之后，他就去做这个和的工作，这里也是一个比较的一种方式。呃，容器的资源。

我们这边有多级的资源的QS分配策略。刚才有提到。实际上K8S它只有两个池子，一个exclusive，一个是default。呃，这两个十字，那它的分配策略就是两种，要么就是一种是独占，要么就是。共享就这两种方式，实际上我们这边会更加的智能啊。分成这四种略种应该也是种的策。第一种就是exclusive，也是k CPU manager本身也提供这种功能么？它可以独占这些CPU核心，其他不可使用这些CPU，那么对于一些利用率的任务，他本身就能把CQ制的很满，然后他也不希望他的这个cash被。开始频繁的，由于上下切换啊，不命中，所以它一般。呃，这种容器会采用这种ex的策略。啊，第二种就是不饱和，这不和这种一般它的利用率不会很高，那他可以跟别人去共享这些核心啊。

比如说best effort类型的，或者是一些嗯。对于这个。是敏级C共享些好处就是这个节点比较空。实际上实际上它可以可能可以比较多的去使用这些CPU资源啊。这有助于整个节点的利用率提升。第三种就是这个。方式就是如这个，他说他只需要的可了他。这个时候其实它只是有一个new亲和性的一个特点在这里。那我们在调度的时候，会把它的这个一定是去调度到同一个new not内啊，不会去做跨new的一个绑定啊，这个时候因为我们调度器可以感知到节点的资源，但也不会存在刚才前面有所说K8S原生那种。

调度，然后因为新不满足要求，然后生产失败，然后又被重新生产，重新调度这个循环的一个情况。啊，把它固定到整个牛氓某个new氓no的内上的共享值啊，最后就是这种immovablemovable就是。完全固定这些CPU核心，但这些他并不独占这些CPU核心，就别的可以去做一些共享，那这个时候我们就可以看到有一些有一些离线集团任务，它是。这个对于呢，使用哪些CPU核心比较敏感啊，他如果一开始他去使用某一些CPU核的时候，他就不希望去再去跳到其他的CP那个就是呃，那会儿为他把C时。时高时低，那其实其他也可以去共享这些CPU核心。那这样的一个CP策略就会比较丰富，我们在这个CPU核心的选择策略上也会去做一个。呃，这几个方面的一个工作，首先就是按照这个调度结果去note上需要分配的核心数，然后。

然后呢，就是去从共享中去节点这个从共享中去选择可分配的CPU。然后在分配的时候我们也去。希望一个pod尽量不使用在同一个物理核上的逻辑核啊，这个是因为由于离线计算的这个CPU利用率很高，这些pod如果去使用逻辑核，反而又产生了这个超方面一个竞，因为一般来说这个物统一。这个C利用率大致有一个相同的走势，那我们也不希望在这个方面去做一些太多的，呃，核心竞争。呃，最后我们来讲一下这个在离线场景下这个。呃，资源拓扑感知调度的一些实践。呃，首先我们在这个在离线场景下还会做一些差异化的重调度的工作，呃，刚才有提到这个，因为在离线混场景。的线会受在线的影响，所以它的算力是波动的。

就是这个时候不再是这种CDR上报的静态资源啊，我的离线算可离线的可用算力是随着在线的。峰值而影响在线负载的时候，离线的力会压制，那这个时候节点上之可能已经生产了很多离线的pod，那离线pod就需要做及时的驱逐来。来达到这种节点，剩余的离线的正刚好满足节点，这个可用离线算力的这样的一个。要求啊，那我们就会有这个Dis schedule，这个组件是社区的一个组件啊，我们去在这个过程中去做一些改造。满足一些可配置的。策略，然后去动态的做一些驱逐，那这里为什么说是所见即所得，因为。每个业务它是有自己的一些指标的啊，比如说A的一些计算任务，每个之前预估E计算的时间有多长么。

这些指标其实是可以暴露出来，我们实际上在驱逐过程中，可以根据这些指标，呃，就知道这个离线的po是否受到一些影响，你比如说它这个以Bo内训练的速度是，呃，每次都是一小时，但是在突然间到到一时间点的时候，就每个开始就比较慢了，开始延了半个小时，一个1万小时，这种情况大概。米进行。业务指标。那同时平台本身也会提供一些指标，因为有些，嗯，我们我们有很多业务，它可能本身自己也没有这个业务指标，那平台会根据一个指标叫这个still time still time去描述了这种。呃，机它被对应的这些C绑定这CPU核心这个在线的一些程度，我们去收集这U。

啊，也是可以很好的去描述这个。这个pod受离线啊，受在线影响的一个程度，然后去综合这样的一些指标，通过通用的metricx，还有业务的这些metrics的话，我们去所见及所得啊，直接可以知道这个po有没有受到影响。然后我们就去做一些动态的一些工作，然后在这种不同混场景下，CPU容器的CPU策略呢也是不一样的。呃。在我们这里内部会有两种场景，第一种是容器CVM啊，离线CVM的场景啊，什么叫离线CM就是。就是我们在一一台物理机上，它实际上每个new上可能都生产了一些在线的CBM啊，那么有的时候在在线。抵用率很低的时候，我们需要去更好利用这些资源啊，这种混播方式去直接在节点上生产一个很大的离线CVM，这个离线CVM内部看起来佛自己就是有了整个物理的所有核心。

啊，那这种离线CM的方式，它实际上啊。这个隔离性会更好，那在这个大规模场景下，是可以比较通用的方式去使用这种，呃，离线CM的方式，呃，那它是在这个物理级的。一层实际上去做了一些调度、核调换。本身这个cfs调度器。啊，在在这样的一个过程中，当在线的CBM，它的。呃，利用率上来的时候，离线的CM实际上。就会被受到压制啊，通过内内核调度器有这个高低优先级的方式呢，离线的PM就会获得更少的时间片啊pod在离线CM上pod就会受到很大的压制，那这个时候实际上呃，在这种恐怖方式下，在线跟离线之间。呃，影响就很低了，因为它是通过这种。呃C。此时通过核。

如果在线这个利用率上来的话，上的离线CM的时间会受到影响么？离线它我们在这里都会通过独占CPU的去止它的干扰，然后在但是在V内核VMF调度这一层，它是保证离线的D，它在的时候都可以实现这种核心的移，来充分利用CPU资源。就是说它可能绑定在某些核心上，但实际上啊，在这个虚拟机这一层，它并不会让它完全绑在这些核心上啊，当这些核心受到压制的时候，能的把这些核使核去，就充分的利用好这个CU资。第二方式就是这种容器的方式，容器的方式。呃，就就是把这个。嗯。

在线的这个pod跟离线的pod同时部署在这个一台物理机上，啊，在这种方式下呢，我们就会通过group去做隔离。啊，离线的po，它那通过c groups去设置一些比较低的一些权重嘛，然后就去获取更低的一些CPU实验片，那在这种情况下，由由于它是通过c group进行一个隔离。我们不能去再使用exclusive的方式来绑定离线pod的CPU核心啊。因为这些离线的pod。正那几个C核是在线峰值的时间，也那C核我们可以看到，如果我固定C。这时候如果在线的D的利用率突突然的话，那实际上。这几个核心可能完全不能用，那离线可能完全就跑不起来，那那这个对应的这个节点上的其他的CPU核心有可能还是可以使用的啊，所以我们此时是通过绑定整个U某几被样子也去整个线的整整个充分去使用这些CPU资源，那在这种两种不同的场景下，我们的这个。

这个饱和的策略啊，资源分配策略也是不同的。那这个时候我们的节点的一些组件可以做一些相应的配置，包括那个内部也可以通过一些的方式去指告诉我们他们需要哪一种。之中。C、核心的绑定策略，从而做到一些更加一些更加灵活的场景。呃，最后我来为大家做一下今天的整个课程的一个总结，呃，今天主要是讲的这个的资源top感知调度，也就是。我们在这个KS中如果如如何通过更精细化的手段拓来进行一个调度。那首先看一下为什么做这个事情呢？就是在这个呃，我们会有讲到CPU的体系结构，这体系结构是现代CPU多采用这种呃的方式。

然后在new的方式下呢，我们就希望保证每个他如果想要有更好的性能，尽量分配在同一个上，尽可能去多的去。是，呃，命中cash。然后后来我们讲到这个肠道的邻居问题啊，就是在这个云计算这样的一个场景下，我们节点上会被多个pod去共用这些go pod由于去增强这些资源导致了。呃，很多不必要的一些，呃，切换工作的一些开销啊，包括存的一些开销，然后开命中率降低的这些开销，那么那么原生的KS中，它为了去解决这种吵闹的邻居问题，他就去设计的，比如说c manager。这样的一些组件，配合top manager。呃，希望去在分配CPU的时候去更加考虑到这个。资源之间的一个竞争。但是它是有一些局限性，首先它局限性就是嗯，调度的时候无法感知节点的这个资源拓，第二个就是这种CPU manager的分配策略是过于单一的啊，比较简单，那么在混播场景下。

还会有一些额外的算力感知问题啊，每个note上它的离线可用的这个。CPU的算力实际上是在发生一些波动的，我们不能完全使用。KS直接静态上报的那种资源。然后。接下来。呃，我们的做法就是通过这几个步骤，第一个就是采集节点的一些拓扑资源。然后去通过CD的方式去上报，然后扩展KS的调度器。药剂在调度过程中也可以去感知到这些节点的资源拓扑。同时，呃。在调度的过程中为pod去分配。呃，资源的一些，呃，拓上的一些资源。然后我们可以看到，我们还有这种多级的资源的QS分配策略。这种分配策略是。

比K8原生的方式更加智能。然后我们可以在一些。场景下，我们可以去自由的选择自己的一些策略来充分利用C的资源。那最后就是road maps road maps，我们会预计在这个八月底将这部分资源拓扑感知调度的功能集成在CRA这开源社区的中啊。资源拓扑感知调度本身是。降本增效的一个很重要的一个环节。那么科研项目也是。聚焦增效这个方面，尽量把集开源项目供大使资源。这里主要说的其实是一些。跟C关的一些东西，那我们今后还会考虑有络拓调度等等的资景做化资度。好了，今天的课程就为大家讲解到这里，感谢大家的观看，谢谢。非常感谢方瑞老师的精彩分享啊，王老师从资源竞争、资源感知等问题出发，讲到了Co的精细化管理，容器的CPU set管理以及在离线分布场景下的最佳实践。

大家可以收藏当前直播链接，回看地址呢，就是我们当前的直播地址，好的原动力云原生正发生降本增效大讲堂截止今天第二期内容就结束了，那让我们来回顾一下我们这两期分享的内容啊，我们第一期呢，聚焦在优秀实践方法论资源与弹性。架构设计在6月23号进行了第一讲直播云原生降本增效优秀时间案例分享，那在6月30号呢，我们进行了第二讲直播cos云上资源的分析与优化，那在7月7日，我们进行了第三讲的直播Co集群利用率提升实践。那我们第二期呢，是主题是我们的一个聚焦，全场景在离线分布Co GPU资源，效率提升，Co资源拓扑感知调度啊在7月28号我们进行了第四的直播，主题是K全场景在列线分布，那8月4号呢，我们进行了第五讲的直播，通过云原生管理Co GPU资源。

那在今晚呢，我们进行了第六讲，国内资源拓扑感知调度。那欢迎大家观看回放，点击我们当前直播间下方的往期直播，或者在进入我们活动专题页面即可进行观看，后续呢，我们也会将直播内容整理成文章，让开发者更便捷的进行学习与交流。千万不要去错过啊，好了，通过两期的原动力原生正发生降本增效大讲堂直播分享屏幕前的你是不是收获满满呢？那我们今天的直播就到这里结束，期待我们在第三期直播再见。