Crane:基于finops理念的极致降本原创

呃，大家好，我叫郭志红，呃，负责腾讯原生产品的解决方案和架构工作，那今天给大家分享的一个主题呢，是基于理念的极致降本。那我今天的主题主要有以下三个方面，第一个是我们看一下云原生资源利用率的一个现状，第二个呢，是我们一起深入理解一下的一个资源管理，它给我们提供了哪些呃本的一个手段，其实同时它也有哪些不足，然后基于这些不足呢？第三部分我们会看一下我们腾讯内部或者是create这个项目是由提供哪些解决方案，以及我们的技术手段，还有我们的最佳实践。那第一部分的话，我们先看一下云原生资源利用率的一个现状。那我首先会分享两组数据哈，第一个呢，就是呃，原生基金会在2021年的一个调查报告显示啊，目前有96%的一个组织已经在使用或者在调研cooper，这也创了一个历史的一个新高啊，那同时啊，Flex这个报告也指出，其实有30%~35%的云支出是被浪费了，这个浪费还是非常严重的，其实我们带着这两份报告也去把腾讯云上的真实的用户数据看一下。

呃，我们抽呃抽取了三份呃数据样本啊，第一个的话就是我们的物理机这个样本，那物理机的资源利用率大概是在10%左右，那虚拟机的话是在12%左右，那我们知道呃容器的话，它是一个更轻量级的一个虚拟化技术，那加上Co这种细力度的资源调度和编排能力，我们觉得容器场景下应该可以大幅度提升的一个整体资源利用率，但其实实际情况啊，我们看到只有14%，其实并不理想。那我们其实我们也分析一下，那么为什么在云原生时代啊，在这种docker这种云原生技术的加持下，在资源利用率还是不高。

那其实我们呃觉得核心原因哈，有这么几个部分，那第一个的话就是说，比如说我们在呃物理机时代，或者是没有上云之前，没有云原生技术之前，那我们是怎么管理呃成本呢，是怎么管理资源，往往是有一个it团队，或者有个财务团队，在年初或者年终的时候去做下一年的一个预算，那这个成本是固定的。那有一个中心化的一个一个方式去统一规划，那上云或者使用原生技术以后呢，就是把这个资源申请和使用的权限往往下放给了我们的业务团队，那业务团队可以按需使用，那虽然这个方便了很多哈，但是的可控性也会差很多，所以就导致业务的不断增长，导致我们成本也会成倍的一个增长。那这是一个原因，另外一个原因的话就是虽然我使用了云原生这个技术，但是他在呃业务在使用的时候，还是像以前申请VM或者申申请物理那种方式去去申请，它往往申请的偏多，所以就导致了整个浪费比较严重啊。

这也是为什么在后原生时代，我们成本管理还是有非常多的一个挑战。那其实这块也给大家分享一组数据哈，就是在腾讯从2018年930变革以后啊，资源业务全面上云，那其实我们到今天为止啊，差不多四年左右的一个时间，整体呃上那个规模达到了5000万，其实大部分都是通过容器化原生的这种方式去去做的。那通过我们的一系列的部技术，那整体的一个资源利用率可以达到65%，帮助整个集团节省成本大概有30多亿。这也是我们在几年做的一些成绩单啊。那我们相信相信大家也对Co也都比较了解哈，那这块主要是为了后面我们的一个切入哈，先简单带大家回顾一下Co它做资源管理的一些能力。

那我们知道Co它是啊，通过生命式的API定义它的一些资源，在节点的话，它叫node，那我们是看一个，比如说一个四核8G的一个no的，那其实它有一些是被给分配给系统的，这些叫system serve或者是Co serve，这些是没法分配给业务的，能分配给业务就是这些，剩下这些，那我们调度完schedule，调度完以后，那往往可能还剩了一些，比如说这些，这些我们叫leftover，就是因为一些碎片或者是吧，调度的一些机制的问题导致这些。资源无法被调度，无法被分配，这些资源肯定就会就是被浪费了。你看这是K提供的一个节点的资源管理能力，那它同时提供了有两个重要的概念，就是request和request，就是说我这个资源啊。

我申请了多少，这个是K调度会根据这个资源去去申请的。呃。还有就是。它有一个limit，就是说我这个po或者这个容器，我最大使用可以到多少，那我通过这两个request limit可以的控制啊，它的一个比例的控制，可以去对集群的资源或者节点的资源做一个超卖，这也是KS给我们提供的可以提升资源利用率的一个一个核心的一个手段。那其实我们看一下一个典型的一个资源利用率，它是什么样子的，比如说我们有一个40盒的一个节点，那它资源总量，它实际利用利用量，那中间这部分都是浪费的，那我们看一下它到底浪费在哪里，那第一部分的话就是说我们这个没有分配出去的leftover这部分因为一些碎片或者调度的问题没有分配出去。第二部分的话就是。

呃，这边过多分配的一些资源，就是说我申请的申请多了，但实际利用的并没有那么多，那就是过多分配了，我们想能不能把就是这条线尽量往下拉，能不能把这个过多分配的出去的，再重新分配给更多的业务去使用，这也是我们第二个可以优化的一个点。那第三个的话就是我们在这块可以看到有一个在线业务往往都有一个波峰波谷，那波谷这部分往往是就是被浪费了，我们想能不能把波谷的这部分也利用起来。那这也是我们整个提升资源利用率的一个。从通过现状我们可以看到我们的一个解题思路，就提升这三部分的一个资源利用率。那其实同时也提供了这种弹性的能力啊，就是说和VPA去帮助我们在业务高峰的时候去弹出来，那在业务的时候去说一些些po，用动态的使用资源，提升资源利用率，那其实有了像request limit这种超卖，或者是动态的弹性伸缩，那我们是不是就可以很好的。

提升整个集群的资源利用率呢？其实我们实践的过程中发现其实并不是非常理想。那核心的问题，其实我们总结下来有三个，第一个就是那资源在配置的时候，比如说request和limit配置多少到底合适，那这个其实。啊，很多业务它是往往很多，呃，或者是业务方或者是平台方，它都是根据一些历史的一个经验值来配的，比如说之前我在物理时代配多少，那我上了容器以后还配多少，这个肯定是保险会出问题，但是往往会会比较配多哈，那或者是他就拍脑袋随便配配一个，那这个肯定是不准。那所以也就是不会配的一个问题，那还有一部分的话就是弹性哈，弹性那存在的一个问题就是它有一个滞后性，比如说弹性往往都是目前的些弹性，都是通过一些监控的指标啊，那我比如说completeul或者S去采集这些节点上的一些指标，我给magic server这个采集往往是有一个一个interval的一个时间间隔的，这个时间间隔上报给magic server，它会去计算，这个计算又有个时间，那我。

呃，计算完以后触发了这个阈值，触发了阈值我去扩容pod那节点，如果资源不够的话，还得扩容节点，那这一系列的。的流程其实非常长的哈，往往需要五到十分钟，那所以导致了一个它弹性滞后性的一个问题，所以很多业务也不被他弹性啊，弹性去影响业务。还有一块的话就是，呃，我们知道CPU它都是一个公平调度的模式，那我在如果是一个节点上装，装的太满，部署的业务太多，那在业务高峰的时候，有一些敏感性的业务就可能会因为CPU的抢占被影响。所以很多业务也不敢配，担心会被影响业务。

这是我们觉得原生它的呃的一些不足哈，导致业务不会配，不敢配，不能配。那其实这是我们在没有去做通过或者通过我们降本方案去做业务优化之前的一个资源利用率情况，那其实看到某个业务的CPU利用率只有15%，内存利用率只有25%，那过去一年的弹性也只有10%。所以这是导致它核心资源利用率低的一个原因。那我们是怎么做的呢？那基于前面呢，我们讲到的我们的呃，三个解题思路，还有我们。会配，不敢配，不能配这样一些现状啊，我们提供了一个全链路的一个降本方案，那其实就是三个步骤，第一步的话，我们提升装箱率就是。让这个节点装的更满一些，那第二的话就是我们去提升整个节点的一个峰值的一个利用率，然后在峰值的时候。

可以啊，让这个节点跑得更满，那第三步的话，就是我们进一步提升整个均值的一个利润。那有了这些呃理念以后，其实我们在实践的过程中，往往需要一些理论的一些支撑哈，那这个理论其实就是films，那其实S他定义了一系列云财务管理的规则和最佳实践哈，他有一些原则，就他提倡我们团队合作，他提倡我们团队，团队中中的每一个人都要有成本优化的一个意识，他同时也有一些一系列的一个角色，比如说有的从业者去制定这些规范。还有就是也也有管理层去推动去落地，还有就是我们的业务人员或者产品人员去具体的做一些实施。那其实它也有一系列的一个一个阶段和步骤，同时想要取得的一个成功，我们也需要，就是他也提供一系列的能力模型，比如说我要理解成本和用量，我要去做绩效跟踪和展示这块，为什么要做绩效跟踪和展示呢？因为比如说在一个大的团队，像腾讯内部有这种，呃，有有几大BG，还有不同的每个BG部不同的业务部门，那可能一个业务就有。

几万到几十万个pod，那这么规模大的一个场景下，怎么去推动让更多的人去朝着一个共同的目标去一直持续的一个努力，那其实这块就要制定一个核心的KPI。同时也要实时的去把这些效果、成果和展示出来。那其实还有的话，就是我们需要一些一些日报或者报表去帮助我们业务团队或者平台团队去实施做决策，还有就是一些费率优化或者用量的一些优化，同时需要我们整个组织的去做一个支撑。这是。

的一个它的一些理念，那其实我们的就是cloud resource anatics and economics，就是云资源分析和优化，它是完全基于up能力模型去呃做的一个成本优化的一个框架和解决方案。那其实Korea它有这么几个部分，核心就是两个部分有D和agent，那D的话它提供了四个模块，第一个模块就是我成本的展示啊，我要明确的看出来，我当前的资源利用率怎么样，我哪些是浪费了，我哪些可以优化。有了这些以后，我们去做一些一系列的资源推荐和副本数的推荐，那这块其实我们可以知道，如果是一个在线的业务啊，那。往往是有一个利用率的一个曲线的，那我们就可以基于的一些呃，一些资源的预测的算法，比如说DSP或者是滑动窗口的算法去预测出来，你在就是根据我们的历史的数据，比如说未来一周或者未来一个呃，过去一周或者过去一个月的数据，去预测未来一段时间内，你这个业务可能需要的一个资源利用率。

可能需要一个资源量，那这块其实就是的一个核心，就是提供一个资源预测的一个能力，还有就是。通过这种去解决我们前面提到的它业务不会配的一个问题，那还有第二部分的话，就是我们也可以基于历史的数据去预测你未来可能需要的一个副本数。就这块我们叫E或者EV智能的弹性。那通过这个去解决前面我们提到的一个延迟，就是弹性延迟的一个问题哈。那还有一部分的话，就是呃，资源的一个预测，我们也是根据历史的一个监控数据，可以分析出来，或者预测出来这个集群在未来一段时间内，它哪些资源，哪个时间段的资源是空闲的，我们给这些资源打上一个external resource这样一个呃，一个自定义的一个资源。

这些资源就可以被一些其他的业务，比如说离线业务或者的任务去使用。那这也是我们在离线混部的一个核心，那有了上面这些，呃，我们基于预测，我们也说预测为盲啊，这是运的一个核心，那预测出来，那我们其实还有一部分啊，就是create agent做的，那我保障业务的一个稳定性，那这块是我们扩展了class，就提供了更多的一个业务的优先级。呃，那业务方可以通过业务的一个实际情况给他配置上不同的优先级，那我们基于t Linux底层的内核，它提供了一个全资源的QS隔离能力，包括像CPU、内存、GPU、磁盘L和网络L的一个QS隔离能力。

那在业务高峰或者是资源紧张的情况下，那高优的任务可以抢占低任务的一个资源，那在一些极端场景下，我们也可以驱逐一些低的任务去把这些资源释放出来，去保障高优任务的一个稳定性，这也是我们认为在做资源或者做资源优化的过程中一个核心啊，就是提升稳定性，所以我们也说稳定性是跟。那这是的一个整体的一个能力模型，除了我们前面提到的一些能力，它其实还有一些一些比如说控制台提供的一些能力，那控制台这块的话，我们有平台方和运维方的一个两个视角，那在平台方我们提供像成本的分布啊，优化的预测类的分析啊，应用的画像等等一系列的能力，那这块比如说应用画像，那我们就可以很根据历史数据，可以看到这个应用它到底是一个CPU密集型的，还是一个网络IO密集型，或者磁盘IO密集型。

那知道这些应用画像以后，我们就可以根据我们的调度策略，把一些。啊。呃，CPU密集型或者网络密集型的调度在一起啊，让他充分利用这个节点的资源。那我们同时比如说还有一些像一些部门的排名啊，为什么要做部门的排名，那这块就是呃，可以通过一些组织架构层面的一些约束和推动其他的业务部门去，呃。去积极的去配合我们去的一些工作，比如说我们给业务打分，那这个业务打分，然后做排名，那排名高的我们可能给一些呃，激励或者是一些鼓励的一些措施啊，比如说我们价格给的更便宜啊，比如比如说他的呃。答辩或者晋升他他可以有一些有一些呃一些优势啊，比如说一些排名低的，我们当然可能会有一些相相应的一些措施啊，那这个就是通过部门排部门排名去做进一步的去推动。

那当然还有一些业务维度的一些视角。那下面的话就是还有一些像呃，这个其实前面都已经提到，像一些资源推荐啊，副本数推荐啊，当然我们还做了很多调度增强的一些能力，比如说我们有负载感知调度，就是根据真实的一个资源利用率去做调度，还有就是拓扑感知调度，就是解决这这种默认情况下跨new调度带来了一些可能业务访问延时的这样一些问题啊。那这块就是性能隔离，就是基于我们内核层面做的。全能Q隔离能力。那在线混部这块的话，我们也做了很多像干扰检测和主动回避的一些能力。

那这是整个的一个能力模型。那我们也提供了一个。呃，对外的一个DEMO，大家可以通过这个地址去访问一个的一个DEMO。可以看一下我们提供的一系列能力。那呃，有了整个昆的一些能力，我们为了更好的去满足内部客户或者外部客户的话，呃，我们也提供了一个产品化的一个能，那这块呃我们知道不管是用呃我们云上的产品t ke，还是我们自建的这种Co，它其实都是这种so否的一个模式，那这种模式下，当然优势的话就是我们自主可控，它有很多缺点，就是说我需要自己去维护整个集群，我需需要投入很大的一个维护或者升级的一个成本。那与之相对应的话，就是这种service的模式，它这种模式可能比较简单，它全托管，他不需要去我业务方或者平台方去维护，那他也提供这种，呃。

按需使用这种能力哈，可以降低成本，但它也有一些问题，就是我so否像service模式迁移过程中可能并不是那么平滑，它需要一些业务的适配和改善，那同时它也不可控，那嗯，那平台方式我看不到这个节点，那可能我需要更可控一些，那其实基于这种so和service的优点和缺点，那我们创新性的提出来这种一个新的模式，就介于这两者中间的一个，我们叫原生的节点。就是既具备这种呃ful的一个可控性，也具备这种service的一个呃，运维简单这样一个能力啊。那原生节点就是我们的核心理念，就是像可以像管理pod一样，通过的生命式的方式去管理一个note，那原生节点其实主要提供两部分的一个能力，一部分是呃帮助客户降低运维的成本，一部分是帮助客户提升整个集群的资源利用率，那在运维这块的话，我们提供了。

呃，平台平台提供了像呃K8S的内核，运行时还有它的组件的一个升级能力，这块只需要用用户去触发，我们会平台方去自动升级啊。还有我们在呃帮助客户呃去排查或者是解决问题的过程中，也积累了很多的经验，就比如说我们可以把提供了更多的像节点的异常的事件，比如像呃文件系统异常，或者内核死索，或者是file PID，或者max大于最大值的一个80%，这些异常我们都会通过k event暴露出来，那用户可以根据这些。异常事件做一个节点的自律，或者是一个一个告警的一些能力。

所以其实我们总的来说就是通过我们产品化的能力啊，提供一个专家的一个建议。帮助我们的业务，或者帮助我们的用户去更好的去维护这个集群啊，提升整个集群的稳定性。那在资源利用率层面的话，就是我们集成了前面我们的一系列的能力啊，包括像智能request推荐，智能副本数的推荐，呃，智能的一些额外的一些调度器的调度的能力，还有还有节点的一些Q能力等等。那同时也你也提供了一个可交互式的一个资源大棚啊，那比如说我们有一个集群，我们发现它资源利用率不高，那我们就怎么去优化它呢？我们这块有几个步骤，第一步的话就是我们先通过我们资源管理大盘分析一下这个业务或者这个集群哪些是浪费的啊，现在的资源利用率怎么样？

那第二步的话，我们筛选出来，那比如说我们提供了一个维度的一个指标，可以看到节点装箱率低的节。低的一些节点，或者峰值利用率低的一些节点，或者节点负载，比如说po的少的一些节点，我们去选一些我们要下线的节点，那选完这些要下线的节点以后，我们也要看一下这个。节电上的pod能不能被驱逐，核心就是。这些我们都如果不能驱逐的话，我们都会展示出来。那然后就是怎么去安全的下线，那这块我们提供两部分的一些能力，第一部分的话就是我们可以看到这个节点下线的一个进度啊，那我们有整体的把控感，第二部分的话就是我们提供了啊一个友好的一个驱逐策略，就是K8默认其实的它的驱逐其实是不是很平滑的，它是先Q掉一个po，然后再起来，那我们的一个优化方案就是先起来一个pod，然后再Q掉一个，就让这整个驱逐更平滑一些。

那就可以安全的把这个节点给下行掉，那下行掉以后，我们怎么避免后续再出现这种资源利用率啊低的这种问题呢？这块我们也提供了一系列的能力啊，比如说像配置节点放大技术啊，像request推荐啊，像原地分配啊，像我们的一些调度能力啊，重调度能力啊，这块就是根据我们提供了一系列能力，用户可以根据自己的场景啊，去选择不同的一个优化手段。那最终我们也可以通过一个报表显示出来，我们的优化效果怎么样啊。那这是我们整体的一个，呃，优化流程，那如果我们自己去做的话，其实会涉及到非常多的一些一些难点，那这块就不说。那其实呢，可以看到这个可交互式大盘的话，我们提供了两个map，一个是no map，一个是load map，就是节点维度的一个的资源。

一个还有就是workload维度的一个资源，可以很方便的看到，就说你这个业务当前的，呃，申请量是多少，申请量是多少，实际使用量是多少，我们推荐的是多少。还有就是我们提供了一个专用的调度器，根据不同的场景，我们也可以选择不同的一个调度策略，比如说有些业务就希望我们每个节点。的负载都是均衡的。那我们知道Co它本身是一个按照request调度，那时间长了以后，我的request或者limit配置的不合理，那久而久之就会造成那有的节点负载高，有的节点负载低啊。那我们提供的负载均衡调度，就是说可以根据真实的历史。

监控数据啊，根据真实的一个资源利用率使用情况去做掉。那第二个的话就是，呃，有些业务觉得可能需要提升整个装箱率。就是说它的一个场景，就是那节点其实已经装满了，但是还是发现资源利用率不高。那这个这个时候，那有的做法可能就是我让业务去把request调低。但这种那业务方那可能非常多，让业务去一个一个调，可能也不切实际，很难推动，那我们就在平台方提供了一个能力，就是说可以把你这个集群的某些节点的资源去放大。比如说我可以把CPU放大到两倍，或者是把内存放大到两倍去放大，让业务更多的去调度上，那同时我们也提供了像这种呃。像这种节点的一个最大的一个限制啊，就是说呃。

防止它这个节点调度太多，那资源利用率在高峰的时候，那它出现了一个一个水崩，水崩的一个状态，我们有一个水位的一个限制的一个能力。那第二第三个能力的话，就是说我可以比如说业务想规整，这个业务有些节点的资源利用率比较低，那我就有一个请说优先的一个调度策略，就是说我可以优先把一些。节点调动嘛。那从而把一些其他的利用率低的节点去去做一个回收啊。那这我们提供了不同的一个调度策略。还有就是有也前面也提到智能负载，就是说是快速推荐，那这块其实核心是还是根据预测。它本质上其实是根据历史的一个监控数据。去根据一些预测算法去推荐一个合理的值，那这块其实是简单来说，就是我们根据你历史的数据，找到你资源利用率的一个P99的一个值，在这个P99的一个值上乘以一个安全系数，这个就我们认为是一个非常安全的一个，并且可以提升资源利用率的一个合理的request。

但这个request也是可以根据你历史的一个负载去动态的去调整。那还有一个能力，就是我可以做到节点的一个原地升降配合，就是说在不重启pod的情况下，我去修改。我这个资源的request for limit配置，那这块其实核心场景有两，一个是降配，一个是升配，降配的话就是说我之前可能配多了，然后为了一些冗余buffer，冗余的太多，我需要降配。但是又不影响，不想影响业务，我就直接可以通过原地降配的，还有的话就是原地配，然后可能之前配的少了，那为了应对一些突发情况，比如说某个pod，它的内存在。

根据一些请求量逐渐升高，那为了不影响它触发OM，我可以临时给他调整它的一个request limit，一个值。那这是我们原地升降配提供的一些能力。还有其实整个原生节点里头也默认集成了我们的在离线混部和QGPU的能力，那在离线就核心解决我业务波峰波谷情况下，在波谷尤其是夜间，它在线业务没有流量，我通过混的方式把夜间这部分也利用起来，这一块其实可以很大程度上去帮助我们提升整个节点的资源利用率。那我们评估至少可以提高三倍的一个资源利用率。那同时我们也提供了呃，我们自研的在内核层面做的一个QGPU虚拟化的一个能力，那这块。

就是提供了详细力度的显存和算力的一个隔离。和共享能力啊。同时也可以做到一个性能的无损耗。好，那今天主要就是给大家分享了一些呃，我们在呃腾讯内部的一些实践，还有在资源利用率提升方面的一些手段哈。那其实我们主要就是我们看了一下当前金融资源现状与一些不足，还有我们或者腾讯内部的一些解决方案以及技术手段，还有最佳同时为了更好的服务内外部客户，我们把这些的能力呃成我们t ke公有云上的一个产品，叫原生节点啊。那不管是TK的用户或者是非TK的用户，都欢迎大家去体验，或者或者是我们的原生节点。

那其实我们做了这么多，本质上还是希望让更多的用户去享受到云原生给我带来的一个技术红利。好了，谢谢大家，我的听听我分享呢，就到这里。