《原动力 x 云原生正发声 降本增效大讲堂》第三讲《Kubernetes 集群利用率提升实践》原创

各位网友大家好，欢迎观看原动力云原生正发生降本增效大讲堂系列技术直播。今天是该大讲堂第一期第三讲，直播主题是集群利用率提升实践。原动力云原生正发生降本增效大讲堂是由中国信通院腾讯云thinko产业标准工作组联合策划，目的是与开发者一同交流提升资源利用率、降本增效的方法与优秀实践。本期我们请到了腾讯云容器技术专家宋翔老师，今天宋翔老师会从利用率提升背景、常见集群负载优化思路、负载提升及稳定性优化三个方面来讲解Co集群利用率提升实践，我们有请宋翔老师。同学们大家好，欢迎来到降本增效大讲堂，我是今天的分享人宋翔。今天呢，我将为大家做一个关于集群集群资源利用率提升的技巧相关的分享。

首先简单的做一个自我介绍，我叫宋讯中心讯云自研的基于容器的应用管理平台。过程们研腾讯腾讯的从零到一的上云工作。在这个过程中，我们的平台主要承接了很多的在线业务，然后规模也高达数百万。核心。下面我们正式的进入今天的分享。今天的主题是CU利用率提升实践。我将分三个部分为大家做一个简单的介绍。第一就是提升的相关背景。

第二是常见集群负载优化的一些思路以及技巧。第三，随着负载提升，可能会带来相关的定性问题，那么我会对相关性优化做一个简单的。首先从第一点开始。其实利大背景四个增效利，然后就会导致我们有大量的服务，需要大量的资源，然后这个成本就会特别的高。一般情况下，可能是因为我们评估的集群的规模比较大，然后有很多的集群的冗余buffer与应对我们的峰值需求。或者说我们有多过多的节点，但是呢，我们的实际服务占用的资源很少。

这就会导致我们的集群的资源利用率比较低。最后呢，有可能是因为我们还有很多的D是在待调度过程中，但是由于我们的的设置不合理，导致群提前使用光了它的所有的资源，无法将继续调度上去，也会引发相关的利用率低的问题。我们要深入的理解集群负载为什么会这么低，首先要从两个部分下手，第一就是它是怎么怎么去定义资源使用，第二点就是no怎么去分配资源。我们先看。首先，Pod的QS的分级有以下三种。通常情况下，Best efforts的情况是不设置request和limit值的。

这种场景实际在我们的网用中是比较少见，因为会带来很多问题。还有一种。就是我们看到的右边最后一种叫做的模式，这种模式下呢，要求用户设置的request值和相等，虽然它是最稳定的，这种情况下并不利于我们集群的资源利用率提升。最常见的一种就是既不是best effort又是又不是的模式。通常我们建议用户的都会设置一个request值和一个limit值，然后request值小于limit值。通过这样request和这两个值的调整，其实是可以做到相关的利用率提升的。第二点就是我们no是如何分配我们套的。如果我是，我们可以看到右图。

啊，我们简化一下no节点，首先我有一个node节点，它有一定的capacity。但是实际上这些资源并不能够完全的被我们的D所使用，首先一部分就是它的系统的保留资源，系统的保留资源就给到我们的操作系统，比如说SD。啊，守护进程，还有就是。这种资源呢，通常预留给以及容器运行及节点上的一些相关的，比如说资源的探测检测器等相关的服务。第三点呢，是有一个叫e thread这个东西。它是为了保证我们的群能够的达到一个值而设立。这些资源其实都不能被我们的所使用，那么剩的资源是可以被我们的实际利用。

然而，实际的情况是什么样的呢？当我们的节点分配完pod之后，比如说我们这个ABC3个pod。可能还会剩余一定的碎片资源。但这个片源有可能它非常小，但是我们调度的呢，比较无法调度这个节点，那就会造成了这个节点的资源的损失。OK，我们说到了上面两种情况。最后我们就引入了一下具体的可能造成节点资源不足的一些原因，第一就是节点的调度不充分。顾名思义就是我的集群还有资源，但是我的节点无法调度上去啊，有三种情况，第一就是的资源太多，实际服务比较少。

第二呢，就是我们为了保证集群有足够的份。然后我们在扩容的时候，或者说我们在极端的场景下，可能会达到集群的容量，但是这个极端的场景通常可能存在几个小时，当扩容结束之后，缩容之后，那集群又到了一个比较低的一个状态。第三点就是管理员预留的集群B资源过多，实际上服务呃很少能够达到这个buffer的预值。这也是存在。第二点就是我们的设置不合理，我们假设所有的都可以调度到我们的。集群的node上，然后node也没有资源再进行多余的调度，那这种情况下其实也不一定能够使我们的集群利用率得到提高。

为什么呢？首先就是用户很难估计自己的request和limit。当然我们建议用户这个request和之呢，需要做一个性能测，然后估算出一个最佳的状态，但这个值其实是比较难以估计的，它既应用的当时的情况有关，又与时段有关，而且还跟历史状态有关。第二点呢，就是用户更倾向于保守的request值和值能够保证利，虽然利率可能相对较，但是它更加的稳定。第三点就是为了满足短时间的峰值，比如说我峰值期间呢，PA可能响应比较慢，但这种场景下，如果我设置了一个大的request值，那就更容易的去满足我的峰值，或者说毛刺的那种场景。

第点呢，就是用置不是特别的合理，比如用，然后建。构建一个file，然后去建像，然后这个时用资源较少。但是如果用户用了一个镜像或者O镜像，然后去建，那启动时就需要用大的，比如C。最后呢，就是因为我们总结一下，就是因为D设置的问题呢，可能导致D本身呢，常年它的负载就比较低，即使集群里面的D我已经全部占满了，但是集群的资源的利用率也是非常低的。

OK，我们总结了一些常见的问题。就开始优化。我们先从用户去说起，因为用户的优化，实际上我们两次分享。兴的话可以参考前两期的内容，第一呢，就是对的这个配置做一个优化的过程，主要依赖于几个手段，第一就是利用历史数据进行回归。可以看到我们这个图里面，我们会根据用户的历史数据去推荐，比如说我们可以根据简单的周峰值，比如说每日均值，或者是每个月的这个均值情况，推荐出一个最佳的一个容的一个request和的一个限制，这样在用户分页面就以看到的哪些工作负载。

不符合。最。如果用户没有通过CD，是通过控制台进行变更。那也可以变更的时候实时的C。还有一点就是说调整我们的类型是什么意思呢？通常我们为。推荐的值一般是一些整数值，比如说零点五一两四八。但我们不推荐用户去设置，比如说1.25和，比如说1.375和这种特殊的合数，这种特殊的数其实并不利于我们的集群管理员去管理我们的集群。

第二点呢，就是设置合力的hpa。呢，设置也是主要是根据我们的历史数据回归，然后能够得到一个比较合理的范围，然后得到一个合适的触发阈值。第二点呢，就是应用我们上期分享的。比如F算法扩容。扩容利。第三点呢，就是设置性扩策，比如说我的服务在每天的中午的时候可能会有一个大的。请求那我们就在每个周五的时段，然后设置一个扩容的操作。

最后还有一个就是在节假日期间或者活动大促的时候，就比较常见的场景就是618活动，或者说啊春节这种活动，需要前的按时段进行一个扩容，那这样的话是可以设置定时完成这样的操作。最后呢，就是可以根据我们的呢当的去置1VPA，因为VPA的容呢，可能会带来很多的负面的影响，所以这里呢就不再为大家做深入的绍。这是一个简单的实例。这是我们腾讯的一个疗相关的，常上涨的非常厉害，然后呢呢，每个星期五有一个抢购的活动，所以呢，它需要一个自动的扩容，当然维持这个应用呢，低峰值呢只需要两个的节点，高峰值的时候呢，通常要至少18个节点，然后均时刻呢，那只需要八个节点，那用户他就结合了和做了一个简单的调整，他的实力范围呢，设置到了二到30，然后它的。

触发利用率呢，是CPU达到了一个值的50%，然后做一个触发。五时，就是比PA的时候，它的成本是下降了60%。

下面呢，我将重点的大家介绍平台。管理员或者说平台测。如何为用户？或者说为我们的集群做一个资源的负载优化。这一部分是我主要分享的重点。首先第一点呢，就是pod的压缩，第二呢就是no，超第呢就是碎片整理。第四是离。当然这在这个过程中呢，我们还要依赖于动态调度，动态驱逐，以及比如说CU的参数优化配额。和这种保留资源的优化，进行一个资源利用率的提升。我们还是要再回顾一下这个图。我们看到。这个node的节点上。它的资源主要是。

去掉以及。Thread的内容才能保证它的这个。啊，节点能够，呃，使用就才能够为分配资源。那我们就从以下几个手段，然后想办法。第一个办法，我们可以看到。我们可以先看图啊。我们的pod分配到了这个节点上ABC，但实际上呢，我们的pod的使用率呢，可能都不到实际申请的50%，比如说我们的pod a和pod b CPU usage非常的低，那这种情况下呢，我就可以对pod a和DB进行压缩，我们去压缩pod的空间。然后我们把。其他的带调度的，然后再塞到这个节点里面，达到我的平均的CPU负载得到提升的。

目的。那我们先简单的做个背景介绍。首先我们的平台主要承载的呢是在线业务，那在线业务就有一个前提，就是它基本上是没有优先级之分的，就说我们的个的其实都是非常重要的，我们不能因为某一个的占用资源特别多，或者说可能导致其他的资源异常，然后我们就去驱逐他。第二呢，就是我们可以看到。我们能够做资源压缩的前提呢，就是用户已经设置了request值和值。我们在这里建议大家，如果说他不知道应该设request是多少呢？我们可以建议用户去设置request，等于当然了。置完之后需我们平台去理一个动的压缩，那个压缩的内容呢，是我们request。

这样呢，我们就能保证用户使用的最大值还是保持不变，但是当用户的使用量比较小的时候呢，我们去压缩这个request值，可以保证在一个节点上能够塞进去更多的pod。第三点呢，就是说这个压缩比我们怎么设置。首先我们可以设置一个全的压缩，当然了这是根据我们的经验来去设置这个压缩，我们期的时候可以设置的非常非常的小，然后随着我们的集群的运营，大家可以不断的调调调整，然后打到一个自己的运那个集群平应用平台的一个最佳值。首先这个值是不变的，那第二点。我们的全局默认压缩不变，它就会带来一些问题，就是那我们的节节点它并不是均匀的，然后它的特性也是不一样的。

所以说随着这个发展，我们就有了一个动态压缩的概念，就是说我们可以根据每个节点的特征，或者说根据我们的pod，它本身的历史数据去改变这个压缩比。比如说我们的po c里面，它本身的压缩比可能设置到50%，可能就觉得它有点。太过了，那我们就设置到70%。我们是可以动态的去调整，最后呢，就是如果有些业务呢，做一些最佳的实践。将自己request和置合理，我们可某些工或者些节点去这个动态的压。

动态压缩的主要的核心工作点是CU的一个原生的能力，叫做mutating web hook。首先用户在创建了之后呢，首先用户根据。根据的申请，比如说是deploy或者里对里设置的呃，Resource的值，包括request，呃，包括cp request，还有request的。当我们第一次创建pod的时候呢，我们通常情况下会对pod做一个默认的一个压缩比的设置。这个压缩比呢，是经过我们的ating webook对我们的进行一个压缩参数，呃，压缩比例的相乘，比如说我是申请一个四核的C，那这样的话，我以一个零五的压缩比，最终创建的pod呢，它就是一个。

四乘以0.5就是两的CPU的这个。当然了，随着我们的运行平台的运行，或者说我pod的运行，我会对它的pod的值会有一个历史数据的回归，那既然有了这个值呢，它就可以动态的在下一次pod升级或者创建的时候呢。去修改它的压缩比，然后达到一个最佳的条件。第二点呢，我们我们想是。我们刚刚想是用pad我们压缩的形式，然后让node可以多塞1.pod进去，第二点呢，我们就是node的节点超慢。我们可以想办法呀，让CUCU这个认为我这个点实际上是比原的承载能力更大的，然后相当于我们欺骗了。

或者说我们叫这些，然后呢，让做的都是错误，这个怎么呢。我们看到右边这个图，原来这个图的承载能力，我简单的举个例子，比如说我们左边的这个节点可能是一个30的节点，然后我通过系列段然调度器认为呢，这个节是一个有的节点，那这样的话是不是就可以让更多的pod调度进来了呢？通过这样调度的话，我们可以看到我们的total usage呢，就会从原位升到一个高位。那他是怎么做的呢？首先第一点，Node和pod一样，我们也会有一个全局的默认的超卖币。这个超卖比呢，也是根据我们的经验去得的，第二我们以根据的这个实时的这个数据数据，或者说它的一些参数，比如说它的CPU，它的内存，它的一些节点的I这些数据。

然后去动态的修改它的超币，以防止我们超的太多之后呢，导致这个集群负载产生一个剧烈的抖动，或者说影响到我们的资源。我们可以看到啊，它的原理跟其实是比较类似的，它的做法呢，就是在我们的我首先我们知道我们的呢，会不断的去我们的no status会发请求到我们的里，它会发请求到我们的apir，那我们使用的no resource overseas这个ating weook，它的做法呢，就是相当于我在上报的时候篡改的status数据。我们看到最右边的这个样文件，我们可以看到第一个文件上面的一个简单的值，比如说我们看啊，Node CPU overs sales这个值，这个ciio是2.0。

然后呢，我们可以分配的这个。A lot。的那个CPU是31盒。那我经过了这个2.0的这个压缩之后呢，它实际上会这个status去改成下面的这比如比如说它的这个呢，就从CP从改。其实这样呢，就当做了一个欺骗了，实现了这个欺骗我们K8S的这个能力。调度器在决策的时候呢，他就会根据这个值，然后去做一个决策，认为呢，这个节点上的资源还是充足的，然后就可以我们的pod调度到这个节点上，然后给予更高的打分。当然了，我们也看到它也有一个叫做no resource overse racial。

Reconle它的作用呢，就是从我们monitor，就是我们的历史的监控系统里面拿到很多的历史数据，就这个节点的当前的，比如说五分钟的，一小时的，七天的，然后去做一个分析，然后根据这个节点的特性呢，去修改它的。呃，压缩比，这个压缩比并不一定是一个固定的值。第三点呢，就是我们的碎片整理了。我们可以看到两个节点。A和B，然后这里有一个调度的POS，就是po g呢，调度A节点和B节点呢都不行，因为节点的资源不满足。那么我们就要做一个事情，就是从B节点里面这个E。Po e，它是可以满足A节点之前剩余资源的这个能力的，那么我们就把这个pod调度到。

A节点。然后呢，Note b就会有一些更多的资源空，这样呢，我把调度到not上，然后实现了一个碎片的整理。碎片的整理呢，主要依赖于我们的和我们的no detect no detect呢是我们node节点上的一个set的一个组件，它呢会实时的将我们的节点的情况以及节点上的碎片状态去上报。上报到我们的这里，我们会有一个专门的node碎片整理的分析机制，然后去分析这些片还剩多少，然后哪些节点呢是可以去做一些的驱逐的，Schedule的动作呢，就是对这个节点呢去做一个动态的驱逐。然后以。

达到我们的调度器呢，可以把新的。调度的调度到这个节点里面来。还有一种常见的方式呢，就叫做离线，当然我们的在线平台一般不会去做离线的这种。呃。这种设置当然了，如果我们的平台足够大，或者说我们的业务呢，主要。在线和离线都有的情况下，一般都需要用在离线混的方式呢，极致的去提升我们的资源的利用率。这个的呃，实现逻辑是比较简单了，就是说我们的D。比如说我们的note节点上有资源的话，那我们就动态的我们的啊离线资源调度到这个空闲的节点上，当这个节点比如说存在了一些啊，可能要引发高负载的预值的时候，那我们就去做一个动态的驱逐，就是离线任务的优先级是最低的。

当然了，离线的实际上实现的话是相对来说也比较复杂的，我们举举一个我们的大数据的离线任务的一个例子是这样的。当用户提交了一些yam的实例之后，样的实例之后呢，他会去。首先。他会到我们的库ne呃A这里，然后进行一个提提交任务，提交完之后，我们的调度器它会有几种决策方式，第一呢，它要根据我们的拓展的调度器，首先我们需要有一个拓展的调度器，然后去管理这些离线任务，当我们知道这些是离线任务的时候呢，我们就需要资源预测和资源的画像，然后为他去调度一些。啊节点，这些节点呢，通常就是满足。

在线业务存在，但是离但是资源使用量较少的节点，我们就会这些。任务呢，调度到这些节点上去。当然。在调度的过程中，如果我们发现我们的调度任务影响到了线网任务，或者说我们的调度任务导致我们的新的在线任务无法调度到新的节点上，这个时候我们就要做这种冲突的处理，我们会实时的去检测在线业务和离线任务的情况，然后呢去对离线任务去做一个检测以及动态的驱逐。当底线任务跑到了我们的实时的节点上之后呢，其实它根据内核的调度，它也不是优先级最高的，我们可以看到上面会有一个，他们会把我们的业务呢，去设置成了一个BT。

这样的情况下呢，它的离线任务的优先级就会变得比较。啊，我们说了很多的优化的方式呢。呃，优化呢，也需要我们的稳定性。首先我们解决稳定性的。一一种途径呢，就是扩容。因为通过提升呢，就会提升我们的资源利用率呢，一定会就引发了我们的no节点的高负载，高负载的话可能就会影响了服务质量，第二呢，就是节点资源呢，它是不均有的负载高的负载低。第三点呢，就是它扩容的时候呢，新的就无法再调度，这种场景下呢，我们就需要扩容的一些手段，还有呢，就是稳定性的一些手段去解决这些问题。

首先我们的扩容呢，也是两层的机制。首先就是H呢，是我们通常所说的我们的节点的扩缩容。比如说我们的节点的利用率，或者说pod的装箱率触发到比如说85%这个值的时候。节点触发了自动的扩容，然后增加node节点，当然我说的这个值，比如说85%，这个呢，需要根据用户自己的平台以及这个业务的特点去做一些参数的调整。过程呢是比较简单的，我们利用了腾讯的海量的资源，当我们的集群在资源不足的情况下达到预值的时候，它就会触发一个水平的节点扩缩容它。去直接调用腾讯云的虚拟机的接口，呃，腾讯云的售卖接口就可以购买到新的机器，然后加入节点，然后完成这样的一个秒级的这个节点的扩容。

当然了，还有一种形式。就是叫做超级节点的形式。我先简单的给大家介绍一下什么叫超级节点。超级节点呢，我们可以认为是一个在集群里面的虚拟的node节点，我们叫做。它在集群里面的展示形式呢，你酷b ctl get no的就可以看到它其实是一个节点，但实际上呢，它是利用了腾讯云的超级节点和EKS这样的技术，然后可以直接的通过腾讯云的公有资源池直接创建出来一个资源。当我们的的，那这种场景下有什么好处呢？就是当我们的负载要做一个短时间的大量的扩缩容操作，或者说是一个临时的这种扩容操作的时候。

我就可以去创建出来很多的这种在超节的，因为它使用一段时间之后呢，它就会掉，这样呢，就不会占用我们的实际上的集群的节点资源。而且它又有一个好处是什么呢？我们直接从上购买的这个资源呢，它可以选择按量计费的模式，比如说我一个中午的时候售卖的一个峰值。或者说我有一个活动的峰值持续了一个小时，那我就完全可以利用这个虚拟节点，或者说我们做超节点上去扩容一系列的D，然后满足这个峰值的需求，然后这个峰值结束之后呢，缩容，然后就毁掉这样呢资源或者说的这个。

钱的这个使用呢，是比较少的。它的底层呢，背靠着腾讯的资源，所以说呢，我们可以近似的理解为它的资源是比较多的。可以。呃，几乎可以无使用的，当然是几乎啊，不是所有，当我们规模大的或就是po的扩容比较多的时候，我们还是需要关注这个资源的。通常情况下，用户其实。比较小的规模，就不需要关注我几十个节点，我就可以随便的就扩上去了，而且这个no pod的扩容呢，它的扩容速度跟我们普通的创建pod呢。也差不多，然后也可以在几秒钟的时间内呢，很快的去创建出来一个这样的。我们通过两层的这个机制啊，基本上可以完成了我们所说的扩容期间保证我们集群稳定性的一些事情。

第二呢，就是我们的两层的动态的超卖压缩机制。为什么说是两层呢？第一层叫做pod的压缩，刚已经介绍过，第二层是noe的超，这个也大家介绍过。通常情况下，这两种手段我们都需要一起去使用。首先呢，关于po的压缩，我们实现了一个从静态的压缩比到一个动态压缩比的这样的一个上升，或者说叫优化，我们呢需要根据pod的这种历史的状态呢，去动态来去修改这样的一个压缩比。同样noe，我们也是根据一个静态的no超值，然后去。

上呃，优化变成了一个动态的这个超卖，然后根据节点的负载呢，进行一个动态的调整。这样呢，利用这种双层的机制呢，我们是要实时的去改变我们no的节点的资源的这些值，然后以达到我们的这个集群的稳定的，而不是说我一成不变设置完一个值之后，然后就不再关心我们的noe节点的稳定性问题。还有我们就是说怎样去做到的。六的节点能够保证它的资源水位的一个比较均衡。不会造成多个node负载不均，那就需要我们的动态调度机制。动态调度机制呢，我们可以看到第一张图里面原生的调度呢，属于一个静态的调度，根据原生的调度的策略呢。我们可以看到NOE2呢，其实它空闲的资源比较多，实际上它就会将新的pod呢，调度到NOTE2这个节点里面，但是经过动态调度的一个算法的一个优化呢，实际上我们会将NODE2调度到我们的，呃，我们会将我们的pod调度到NODE1节点上。

因为什么？因为NOE1节点上的真实利用率其实是更低的，如果我们把D调度到NODE1上呢？会提高NODE1的利用率，进而呢，提升我们的这个节点的平均的负载呢，是比较接近的。机制呢是这个样子的，首先我们需要有一个叫做note scholar的一个东西去给我们的noe去打分，这个打分的机制呢，它包含了多种多样的参数，也包含了多种时段的参数，这样我们在拓展库那个库schedule的一个调度器的时候，就可以拿到我们节点上的这些参数信息，然后对它的一个参数信息呢，做一个权重的决策，然后以达到呢。

它能够尽量的将我们的新增pod去调度到一个真实水位更低的CPU使用。我们动态调度呢，我们可以看到第一步就是我们先根据有一个叫做。的东西去打一个，我们会根据各种各样的一些。指标，比如五分钟一一小时或者是一天的负载去打分，第二张呢，右手边我们对这个分数呢，会对，比如说5CPU去打分，然后内存去打分。经过打完分之后呢，动态调度器的这个插件会根据不同的权重，然后去做一个这样的累计加累加，然后呢，我们的节点做出一个真实的打分。

比如说我们的节点的打分最高呢，我们的新的pod就会调度到节点一上去。还有呢，就是说我们的动态驱逐，我们知道就是我们的负载不均，或者说我们利用率更no no负载不均或者no利用率啊，太高的时候呢，一定或者说大概率会影响到上面运行的po的资源，那这样呢，我们就会根据这个node的一个状态信息，然后是否达到了阈值啊，各种各样参数的阈值，以及它上面的pod的实际利用率是什么样的。然后对上面的pod进行一个驱逐，那这里的参考维呢，也是多维的，比如说C，如说比如说fd I no，这些都会影响到我们的决策，这个值呢，也是根据我们的业务的特性啊，它的权重和它的指标都是不一样的。

需要我们的通过不断的实践去调整这样的一些参数。这个图呢，就是我们在线业务集群的一个。状态了。首先呢，我们可以看到我们的某一个公共集群里面的在线服务在超卖后是83000。左右在超慢前是59000盒左右，说明我们对它进行了一个接近2万多的一个2万多的一个超卖，然后这个时候呢，已售卖CP就相当于我们这个集群调度。CPU呢是78000，其实相当于我们就已经超过了他原原原来申请就是原来集群所能承载的59000。然后呢，这个集群的节点呢，超卖比大概是在1.4左右，然后lo平均被压缩到63%。

经过这样的一个超卖压缩呢，这个节点在线，这个在线集群呢，节点的平均利用率呢，能够达到接近40%，其实这个有38.7%左右。然后下面这个图呢，就是我们经过一些压缩和超慢手段呢，如果我们不做动态调度和动态驱逐呢，它的节点的负载可以看到它是非常的不均衡的，然后方差值也比较大，但是如果我们经过了节点超卖和呃，我们经过了动态调度加动态驱逐的，它的这个节点负载呢，就更趋于稳定，趋于稳定的好处呢，就是异常的弄就会变少。然后呢，我们的资源利用效率就会变得更高。好，我的分享就到此结束，谢谢大家。好的，非常感谢宋晓老师的精彩分享，宋晓老师为我们介绍了利用率提升的背景，常见集群负载优化的思路以及具体的措施。今天的内容完全是干货的满满，大家收藏我们当前的直播链接，回放地址呢，也是当前的直播地址。

原动力云原生正发生降本增效大讲堂的第一期直播的内容就到此告一段落了，那第一期我们分为三讲来呈现，第一讲是云原生降本增效优秀实践案例分享，第二讲是Co群上资源的分析与优化，今天这一讲是Co集群利用率提升时间，那每一期都可以观看回放。原动力云原生正发生降本增效，大讲堂的第二期呢，我们也在筹备当中，第二期也将分为三讲进行直播，第二期技术直播内容聚焦在离线混布、GPU计算资源的弹性使用等等，那第二期初定分别是在7月28日、8月4日、8月11日的晚上八点到九点钟进行。

欢迎大家预约观看，OK，我们今天的直播就到此为止，我们下期直播再见。