由我和我的同事胡琦铭一起给大家带来一个分享叫做当Finnops遇到云元生Finnops是什么它本身就是云成本管理或者云成本优化那么我们就希望看一看借助云元生的这个技术站我们能对云的成本做怎样的这样一个极致的管理和优化好 那简单做个自我介绍我们两个都来自腾讯云作为腾讯云的技术专家也是我们开源项目就是成本优化管理的Crown这个项目的联合创始人那启明是我们这个项目的开源负责人那我个人是Sinsef的大使也是Coopinator生产化时间之路的作者然后我跟启明也一起翻译过Cloud Finnops这本书那我本身是极客时间云元生训练营的讲师启明这边主要就是各个峰会的一些活跃演讲者所以大家关于Coopinator各方面的一些技术有什么样的点可以讨论的话欢迎大家后续持续交流好那我们为什么要做成本优化这个事情大家我相信经过一天的技术步道大家应该听到很多这种令人兴奋的科技创新点对吧各种先进的技术那很多人其实不太关注说我这个新的技术它的成本到底是多少它有没有给公司带来价值通常这些问题都是解经营者要去关心的事情那为了满足就是腾讯从2020年到2021年开始就在做权量的应用的容器化在这个过程中成本一直是我们最关注的一个点为什么做成本优化这里面其实有外在的因素和内部的因素外在因素是什么呢我们很多的这种调查报告显示Coopinators它一定是未来的趋势虽然现在的占比可能不高现在通常一家公司大概原生的技术占比大概在15%左右但是它的普及度越来越高你可以看到它是一个上升趋势所以Coopinators是未来的很多人坚定看好的一个方向然后另外一方面就是大家随着不断的上云但是成本其实是失控的也有很多报告去佐证无论是Flexura还是Gatner还是中国的IDC这些调查报告都显示有30%的成本是浪费的那你想一想如果你一年花一个亿在云上那30%的成本是非常可观的一个事情那我们就想能不能利用我们作为云原生技术专家以云原生的各种调度技术去做极致的成本优化这个企业带来的收益是非常之大的这是我们做这个事情的外部驱动内部驱动腾讯自研业务非常之大规模非常之大我们有100万台物理机有5000万盒的CPU要去管理来支撑腾讯自研的所有业务所以这个规模我们节省10%的成本这个收益是非常大的一个数字然后这就是我们做这件事情的一个动力那想给大家介绍一下什么是FinOpsFinOps是financial operation其实我们大家都知道DevOpsDevOps是我们通过各种敏捷的方法通过标准化的一些流程的定制包括各种工具来实现敏捷的应用发布和管理那FinOps就是类似的它也是一系列的方法一系列的工具说你企业要去实现云城谋优化你应该怎么样去做所以FinOps本身也是有个基金会的它也隶属于Linux基金会FinOps它更多的是去定义这种方法论的框架和一些最佳实践Cloud Native又给我们提供了各种技术的手段所以我们就在想说我们原生的技术站能够在FinOps所定义的各个阶段FinOps说你要去做云城谋优化你首先得感知成本然后你再去优化然后你通过持续运营去实现这种不断的成本降低这是FinOps所提出的一个三阶段理论那么针对任何一个阶段Cloud Native又有很多的这种技术手段去支撑比如说Cloud Native是面向应用的那么这种声明式的定义它你对任何应用层级的这种成本的开销和趋势的分析就变得非常简单了那么它就可以支撑成本动差这个阶段比如说Cloud Native提供了很多的统一观测提供了一些用量那么基于这些我们就可以去对业务去进行资源的画像那有了这个资源画像我就可以去做一些更智能的调度我就可以去做一些极致的这种成本优化那么第二阶段我也有很多工具去支撑那么第三我可以从运营的角度Cloud Native这种技术架构下面我也可以有很多原来做不到的一些运营的一些指标或者是一些模型原来定义不清楚那么现在我也可以做到了所以就是原生的这个技术站就为Fendals提供了一个全方位的支撑那么除了三阶段Fendals还去建议说你要去在一个企业里面去做成本优化它不仅仅是技术上的事同时它也是运营上的事那么运营要成功就离不开组织架构的支撑那么组织架构支撑就需要决策层的授权然后要有Fendals团队的整体的把控有平台策和应用策的这种团队的支持这个事情才能走下去那腾讯是怎么做的呢腾讯也做了类似的事情这个事情当腾讯有这个组织架构的时候其实我们还不知道Fendals的这些方法论但是我们最后发现我们所做的这些事情跟Fendals基金会所推崇的方法论是不谋而合的那怎么做首先我们每个事业群会有一个技术委员会这个技术委员会会由整个事业群的最大领导所有的高管作为这个技术委员或对委员那么他做什么呢去做授权去做跨团队的拉通那么把这个事情从上而下去做授权然后接下来的重要的一个核心组织就是我们的运管团队运管团队做什么他管所有资源的规划和定价那么同时他会推出这种程序度模型来考核所有的平台和所有的业务考核你做得好不好然后这里面我们内部实现了这种最终的就是因为有济费所以我们会平台去做真正的济费就是这个平台虽然是面向腾讯内部业务的但不是免费的你业务要用的话我像公有员公有员一样给你济费这样的话那么每个团队在使用资源的时候他就知道这个东西我是不是无成本的一个平台那么他就会有动力去做这种成本优化那这是运为手段去保障去保障那同时我们提供了这种灵活的济费模型来牵引业务去用什么样的设备去用哪里的设备这是运为手段那么它是我们整个运为的最核心那接下来就是我们的应用和平台测如何去配合运管来实现公司级的成本优化就是这么大体量下我如何去驱动整个事情所以它离不开阻止的支撑这个过程中我们推出了一个云成熟度模型这个成熟度模型就会去考核平台和业务举个例子那你平台用得好不好我就看你利用率我看你HPA我看你的大核心还是小核心就是你的这种业务架构我看你是不是无状态的是不是可以授权平台扔1000亿这些事情这样的一个公式来考核所有的业务平台是类似有了这样的一个考核公式有了一个标准的KPI那每一个人或者每一个部门其实就有了一个明确的目标说我要达到多少分那我离每一项的分数哪一项分数差得多我就应该去有真正性的去做优化这样来引导业务去做持续的优化这是我们的一个济费模型这个模型看起来很复杂其实它的逻辑很简单就是你一个业务跑到云上你要用CPU要用内存要用存储要用网络那每一个资源都有它的单价所以我们会有一个基本就是Unit Price一个基本的单位的定价这个定价怎么来的呢就是资源的采购成本出于乘上它的销售率售卖率我们叫售卖率比如说我一个CPU是50块钱买来的但是我买100个CPU只能卖出去90盒卖给业务10盒是空闲的那我就得考虑到这个空置的成本也要谈给业务那如果我能卖出120 130的话那我就相当有超卖了那我这个单价就下幅对吧我闲值的越多我这个单价要越上幅这是一个基本的一个成本定价然后呢会有一个灵活的discount模型就是说我们本身这个设备都是一购的地域也是多种多样的那你用旧代词的设备你用便宜就是那种比较性能比较差的设备我一定会给你折扣你在北京 南京要用北京 或者广州这种热门地域要用设备那价格可能高但你用一个我们闲值比较多的地域的设备那我就给你折扣通过这种灵活的这种折扣来引导业务去使用我们希望优先消耗的那些设备那这张图就是更多的是我们在整个优化过程中所总结出来的一些方法论吧就是说我们要去借助Kubernetes的这些手段去做极致的成本优化我们应该从哪开始一步一步怎么样去优化有哪些地方是可以优化的那么第一步通常我们在讲Kubernetes的调度手段都是在讲它的装箱的对吧业务需求是多少我下面有多少资源那么这个就叫做通常我们把业务调到到我的这个集群里面叫做装箱对吧那所谓的装箱率就是我有100个CPU能装进来多少对吧所以第一步通常我们是希望去提升整个集群的装箱率那这里怎么做呢Kubernetes的默认调度器比如说Kubernetes的默认调度器它是均衡装箱对吧就是哪个集群机器更显它就往哪装那么这种手段就会它是面向更优于性能的就是它均衡整个集群的负载但是会导致如果你业务很少就是每台机器它都占10%或者20%对吧那你整个集群其实有大量的浪费那么这里面我们就会去做很多的这种策略调整比如说我去做装箱可能很简单的一个策略调整就能够实现很大的一个提升比如说装箱那我可能三台机器装满然后剩下机器全空调空调我就把它退回这样的话我整个的集群利用率就上来了对吧这是第一步那第二步呢就是我装箱率上去了以后但是我集群利用率不一定高很多业务会过配的它会超配对吧每个业务都认为自己需求是最最自己的业务最重要我就要最好的硬件最多的这个资源对吧那么它超卖了以后就是它超配它本来需要一个CPU但它需求10个CPU那就会导致即使我装箱装满了整个集群的利用率也不高对吧那第二个部分我们就开发了这种面向利用率的负载感值调度期就是如果一个节点它的负载不高即使你request已经装满了我还可以继续往里面装那这样的话就是我既可以保证在保证业务稳定性的前提下我可以尽量高的去提升业务的部署密度对吧那么第三步就是我单集群做了很多优化那可能这都是我们在时间过程中遇到的很多场景一个个总结下来的我可能会发现哎说我这个集群已经满了就是内存已经满了但是另外一个集群内存很多那我能不能把这批业务签到另外一个集群去所以我们就去推出这种跨集群的调度和重调度我希望把一些业务能够智能的发现说另外一个集群有内存资源我把它签过去还有这是我跨集群都做完了但是我依然会有一些资源是有平静的那这个时候说明什么说明我的机型不匹配对吧所以我在扩缩容的时候去做机器上架的时候我要去选择更多的是适合我业务需求的这种机器那就是我们下面的一个阶段然后最后还有就是有些业务确实非常非常你对需求不合理你可能CPU内存比可能是1比10或者1比20那这种时候我们就提供了很多的能力去帮业务去做优化比如说内存卸载等等技术OK那其实刚刚所说的整个的Trail Map就是我们一步一步地做那最终的一个实现就是我们这些技术技类就是针对提升装箱率我们去做了这种策略优化把这种均衡装箱转成紧凑装箱这里面其实就非常简单了你可能认为说好像也没什么没什么创新只是调了一个profile那这里面其实也有很多机类比如说纯CPU机群你调成什么profile然后GPU机群你可能要用另外一种profile去调对吧那彼此的权重又是怎么配的这里面就有很多的数字数字的调配在里面那么还有业务迁移非常重要为什么重要我们为这个事情做了大量的工作很多业务是有状态的那有状态意味着它不可遣疑对吧那我平台随着业务的扩容缩容我很容易出现一台机器上剩余几个泡的这种情况在这种情况下面如果业务不允许遣疑那我这个细节点就都控制了对吧所以我们就开发了说你是不是授权平台可遣疑如果授权我就自动遣疑不授权我要通知遣疑所以我们做了一个通知的工作流来告知业务说这批节点要下线你来授权那面向利用率的这种这种调度呢就是我们刚才我说的我基于业务的资源画像节点的资源画像来面向利用率去调度而不是面向Cobanitis的这种request生命式去调度还有我们挖掘了内部的这种进线业务基于Fuzz的像这种事件驱动的业务我们认为它可以是进线的我们就把这种进线业务基于我们的内核能力去实现了差异化的SLA的混布就是我在线和利用率线混不在一起那离线的入口就是我们的Fuzz平台那边过来的这种这种job都是以更低的优先级运行在我们的集群里面好我们有很多的技术积累我过得很快因为我们时间很短我们就在想说这么多的技术积累我们有没有办法把它共享出来能够让整个社区也得到回馈所以我们就开远了Corin这个项目那接下来去让我的同事齐明来介绍一下Corin谢谢凡杰凡杰正如刚才说的我们将腾讯这几年的一些总结和思考然后做了这样一个开远项目贡献到社区也就是CorinCorin呢它这个名字呢是来自于Cloud ResultsAnalyticsand Ecomathy这个整体的一个缩写那Corin它是一个Fingups的一战士的平台也就是意味着你可以去通过一键安装的方式就可以直接去使用了那么在社区的一些经营方面呢它也是Fingups的Foundation我们前面也介绍到了Corin是第一个通过了Fingups认证的开远项目然后从国家的一些一些评比和奖项上奖项上来看的话Corin他也拿了一些国家级的一些认证和奖项这个有兴趣的话可以了解一下下面介绍一下Corin整个的项目的一个架构那么首先呢我们会有一些基础的开箱机用的功能包括一些成本的观测成本的分析和成本的展示还有一些基础的能力那么我们会把放到一个基础的组建叫CorinD它是一个KBS中的Department那么在接下来呢我们会把一些高阶的调度和重调度的能力放到我们的一个组建叫Corin Scheduler它也是一个调度器但是呢它是兼容了KBS的Scheduler From Work去实现的那么在混布方面呢Corin我们也提供了一个Agent它通过Demon Set的方式不处在每一个节点上那么这个Agent呢它会跟我们的一些Ninux的一些能力比如说一些C Group的一些配置做一些整合提供一些混布所需要的资源的隔离能力当然整体呢我们还会依赖监控的系统比如说普鲁米修斯因为我们在做一些一些成本的分析包括应用的分析的时候它是需要从监控系统中去拉到一些Magics数据的那么下面的话因为前面我们也聊到了很多一些一些技术方案包括一些思考那么接下来我们会讲得更具体一点我们通过三个User Case来去跟大家分享Corin我们最常见的用户所会使用到的一些场景第一个场景这个用户它的使用是这样的它把它所有的集群里面的整个CPU的使用汇聚到一起进行了一个分析它就发现它的这上面全是再性应用它的再性应用CPU的利用率平均在10%左右整体在5%到15%之间徘徊那么我们可以发现这其实是有一定的自愿浪费的同时我们也去帮它去分析了一下它很多的再性业务应用去设置的时候它没有做一些自动的分析所以说应用的管理者或者运为它去配置它的应用规格的时候是凭自己的一个主观的一个感受就配的所以说这里的话就有一个可以优化的点可以使用规格推荐来去帮助它规格推荐这个能力它是说我们定义了一个CID叫Recommendation Rule这个CID它会去Group一些KBS中的资源比如说一些WorkloadDepartmentStable Set等等同时它还会去定义一些周期性运行的参数比如说每天或者每小时会去跑这样的一个推荐的任务那么这个任务它在运行的运行之后就会生成一些推荐的建议这些建议我们会针对不同的资源类型来给出不同的推荐结果比如说如果是对于规格的推荐我们会给出一个推荐的推荐的CPU和隆存的规格如果说是一个副本书的推荐我们会给出一个推荐的副本书那么这一套系统我们推荐用户可以去这样去跟它的系统做集成第一种方式是集成到它的控制台中它可以看到它的应用有哪一些work load是可以做优化的那么它就可以在这里触发一次应用的重新发布来更改它集讯中的规格另外一种方式是我们可以通过跟它的CICD pipeline集成它的PubLine中可以检测到它的应用有没有关联的推荐对象而且自动生成一个pro request那么当用户它review完这个request之后这个代码被核过之后它就会通过CAD的流程自动地更新到它的现场集讯中了最终的一个结果我们可以看一下这是我们的一个用户的这是我们一个集讯中它的容器的一个规格的分布很作标是CPU通过标是内存在使用推荐之前它整个的一个规格的分布是偏大的那么在Apply完我们的一个推荐结果它整个的规格的分布有一个显著的降低那么这是我们第一个UserCase的一个结果我们的应用它的整体的CPU的用量在没有显著的降低的情况下基本平稳的情况下它的总共的CPU的这个总量有了一个显著的降低降低了25%这是第一个Case第二个Case这个用户它是一个云上的用户然后它的应用有一个显著的潮湿性的一个变化同时它的应用也做了一个云原生的无状态的改造所以它可以Scale第三个就是它一直在使用我们云上的一些Auto Scaling弹性的一些特点它就可以快速地去对它的集群做扩容和缩容那么这个场景我们就很容易想到我们可以使用KBS中的水平声说的这个能力来去做但是KBS的HP它有一个问题它的扩容是依赖于实时数据去做的那么它的一个问题是当我们的流量真的来临时候我们的业务往往是来不及扩容的所以说为了解决这个问题我们引入了EHPA这样的一个概念它通过一些算法来提前地实现一个扩容那么这里使用算法是时间序列的预测算法我们去把过去一段时间的时间序列进行一个分析来预测未来的一个周期那么把这样的一个数据再往前重放之后我们就可以做到提前的去扩容了同样的原理因为我们知道未来它的数据的走势我们就可以避免一些没有必要的扩容比如说它的这个负载下降之后又立刻快速地又回升这种场景我们就可以提前地去感知并且不去做扩容那EHPA同样的我们还支持了GQ Chrome-based的一个scaling因为我们在一些节假日的场景或者说它的业务明确知道它未来的一个扩容计划的场景还是可以去做这样的GQ Chrome-based的配置的那么这个策略会跟预测追问的整体的去做一个merge就两边取一个较大值来做兜底整个的EHPA它的对象这是一个例子基本跟社区的HPA是兼容的唯多了我们的预测部分的一些远数据和GQ Chrome-based的一些配置除此之外我们可以实施一些Draw-round的能力就是你可以通过Draw-round的方式去跑HPA来去观测它的一个行为那么除了HPA以外我们的业务要想在云上做坦信我们还需要对集群的对集群本身做一个伸缩那么我们可以想到可以使用我们的Cluster Autoscaler那这个能力的话也是比较成熟但相信大家也比较可能有些了解就是我们的集群一旦出现它就会自动地去扩容那么但是同时如果有节点它上面泡的消失就是没有了节点之后一些空了节点它就会自动把这些节点再缩掉那么在用户的这个用户的场景它是这样去做的首先它会去购买一些一批机器GPG系是包连抱月的它会把它的业务部署在GPG系上同时GPG系的容量最好是满足它晚上的时候它的业务的容量那当白天业务缝缝来临之前通过我们的预测算法它可以提前地去做扩容那扩容出来的泡的会产生一些喷顶的泡的因为它的集群的容量不够这时候它就会自动扩出一些安量机废的节点出来那么这些新的泡的就会涨到这个安量机废的来等支撑完这个容量合共之后这些泡的它会缩回去那缩回去之后GPGP是因为是它使用的是DepartmentDepartment它在缩容的时候有些人会缩那些新涨出来的泡的所以GP节点它的泡的再被缩光之后它就成为了一个空了节点空了节点又会被Cluster的Outer Scaler给回收这样的话它就做到了晚上的时候它又退回原来的爆裂爆裂的机群在这个场景中最后用户的一个结果是下面的部分是我们预测的一个结果就是即便比较斗动比较有毛刺的是它实际的一个业务的流量的一个走势那么跟它贴着的这条线是我们预测出来的一个走势可以看到还是比较准确的那么基于这样子的一套架构它整体的利用率在峰值的时候百点的时候能达到70%那一天下来整体的平均的利用率在40%那在一个存在线的一个用户场景中这个利用率还是比较高的在第三个场景我们的这两个场景我们的用户它遇到了一个问题是这样的就是它的集群它的装箱率已经做的比较好了已经做到80%了但是它翻译两个问题第一个问题是我们装箱做到80%再也上不去了因为它的集群中的节点有很多是比如说是CPU内存比是1比2的但是它的业务很多是1比4或者1比3的这就导致了部分节点它的一个资源一定是有一些碎片的这是第一个问题第二个问题是它的节点虽然装满了但是直接的使用量却差异很大有的节点它的使用量非常的低但是有的节点使用量有非常的高产生了一些不稳定性的一些因素那怎么解决这两个问题呢对于这个我们节点整个分布不均的问题我们可以想到可以通过调度和从高度的方式来去做我们知道社区的scheduler它的一个调度是基于request去做的那么这就引发了刚才用户的问题所以我们可以考虑到可以通过实际的负载来去影响整个调度的打分比如说我们这里这个场景我们设立了一个调度的守卫线是45%那么节点3它的一个一个小时的最高的负载到了70%所以它超过了这个守卫线它就不会被调度到这个节点上同时呢节点1和节点2它5分钟之内的负载的纸偏高所以我们在调度打分的时候我们就会優先把新的泡的调度到这个节点1上面在重调度的场景下我们这里设立一个重调度的守卫线是60%的负载也就是当这个节点它的一个load超过60%的时候我们就会把我们就会把这个节点上的泡去除直到降到什么值呢降到我们的是50%所以说在这个场景下我们就会触发这个节点的重调度把这个节点上的泡的驱逐到集群中负载较低的节点上这个就实现调度和重调度整体就实现了集群中节点利用率的一个均衡那么针对于刚才讲的第一个问题碎片问题怎么解决呢我们做了offline的重调度的能力它会在每天的晚上的时间去计算我们这个集群中所有的这个节点节点和泡的装箱情况使用兵派的算法重新的进行调度来去计算因为我们的调度它永远是在那个时刻的最优节我们理线计算是可以得到全局的一个最优节这样的话算出一个全局最优的一个调度结果那么它就发现是不是通过一些我可以疼多数一些节点出来那么就会生成一个最优的这个装箱的这个计划那么就会跟我们线上的这个装箱计划做一个比较就会生成一个migration的plan那最后的一个效果我们可以看一下首先从集群的整体的这个平衡度来讲它的在线的利用率到了48%因为我们装箱率也有所提升然后整体它节点的利用率的方差降到了10%在前面那张图上它是20%然后我们再看一下碎片的问题我们整个集群中它的装箱率大于超过了95%并且呢我们集群是一个eGo的集群就是说它也有一些IP的除了CPU内存以外还有一些IP的资源还一些GPU的资源整体达到了95%以上的装箱率最后我们来看一下可认这个项目的一些用户的情况就是大家实际的落地的一些场景那在内部的话可认这个项目是我们集群中默认安装的一个组件那么在线的核心管理的是7个billion理线的同时在理线的集群中我们也reclaimed的7个billion的CPU用来去支持一些理线的job那么在功用上TKE的一些能力包括超级节点原生节点TTCC等等都内置了可认里面的部分能力然后在开源的用户我们也有好多互联网的获得一些传统企业也在使用我们的项目那对于未来的一些计划我们可能会从这几个方向去做第一个是一些基于算法的一些调度第二个是基于一些AI算法的预测第三个是我们的一些current自己的节点的超卖的方案第四个是跟CICD框架的一些集成那么主要内容值这么多现在来就是有些问题的话可以写讨论一下我就有个问题就是我看过FINOPPS基金会的一个演讲它有句话非常的经历就是更高的利用率并不意味着成本跟低然后跟低的利用率也不意味着成本更高那比如说举个例子就是AWS它那个计费模型每个计费模型有成可能有上百种有sport instancereserve instance还有一个andemn还有一个包廉包业那这种不同的模型下相同的资源价格是千差差距非常大的比如说sport instance可能只有一折你就算买16斤你就算80%的利用率我那个sport instance可能就1%的利用率但我仍然比你低就是仍然比你耗费的那个更低那就是说crown对这方面未来会不会做相关的一个眼镜或者设计就是这方面很好的问题就是finals其实两个大的方向一个是rate的opemise一个是usage的opemise一个是费率优化一个是用量优化那费率优化其实很多能力是就是你收到一份账单你这份账单如何拆解你有哪些设备类型保年保月的然后这种暗量的然后这种sport的可抢占的就是它的费率是不一样的那finals一方面是说你应该用更便宜的资源在刚才那张图里面其实有一部分是体现了这个部分就是我们有一页回头你可以看一看那个ppt有一页是费率优化就是我们怎么样把最更高的价格的这种这种资源换成更低价格的这种资源比如说我们的理线资源其实就是在腾军内部可能就是二折三折的这样的一个定价那我们会牵引说你这个业务如果不是敏感型的那你就来用理线资源那你付出的代价是你的sl可能会下降但是你成本会更低那这里面你就可以更大手大脚的去用资源了那还有另外一个方面就是我们就是这个层面current的成本可视化的部分其实是有去做一部分的支撑就是怎么看你的账单然后另外就是current更多的测重的是偏重说我们调度的技术手段去做这种用量的优化就是usage的optimize他的问题是怎么解决cold start如果是一个全新的项目的话我们确实是要等一段时间的因为有两种场景是这个项目它之前没有接我们的current那么这时候它接了之后因为那个时它其实是有历史的一些监控数据的这时候是可以直接拿到我们的推荐结果海洞场景是它是一个全新的项目那这时候是没有推荐值的但是如果想做的话其实也有些思路我们可以对一些应用去做一些如果你之前有一些应用已经不上去的话是可以做一些巨类的如果有一些AR的能力的话我想问那个关于不在感觉调度的一个问题就是如果它那个我看它是用的重调度器如果它超用了的话是不是不能够及时的重调度就是可能那个就是那个重调度器可能感知没有那么就是它可能一瞬间超用了这种情况下可能会有些是不是会有些故障之类的是这种情况怎么避免是的其实从我们从需求上来看如果它这个业务它一瞬间超过了这个水位线是吧这是我们如果把它是不是不希望对了 把它重调度走是吧是这样的一个需求但其实我其实是比较赞成就是说如果它一瞬间超过了这个水位线我们是要等一等的因为它有可能是一个它过一段时间它又下来了那这种场景我们其实可能稍微等一等会更加保守或者更加安全一些第二个问题是你刚刚讲到它会设一个水位的那个预指那个预指的话那个设置的话是有什么经验的推荐吗还是你就讲的是设置什么百分之四十多是吧百分之六十多这样但是这个只可能是不是不同的应用它那个耐受性也不一样这个而且有可能一个集群中不只是一种应用它可能多种应用它的耐受性都不一样那是不是说不同的应用它那个耐受性不一样的话你这样设置一个预置可能也不太不适合这个有什么建议吗首先我们是有一个默认的这个配置的就从腾讯的经验来看的话一般比如说说百分之六十的这个水位线对于在线业务来讲是是我们的一个经验纸吧就是它可能超过了这个纸之后它到百分之七十百分之八十在线业务的Latency也就会影响比较大了对然后还有就是我们因为是个大来自原池应用它是跑在一起的所以说很难出现就是同一类型的业务在一个线点上这样其实它的利用率也上不去嘛所以说我觉得我们那个建议纸是百分之六十对ok ok ok理解超卖比的话就是我们有两套方案一套是静态超卖一套是动态超卖然后静态超卖的话基本上就是你你对这个容量做一个静态的扩容比如说我就像对这个节点做1.5倍的超卖那你就成个1.5然后还有一种动态的超卖我们是基于节点当前的一个利用率就是你射1.5但是你射的这个1.5可能是这个超卖的上限它具体是多少我们会随着这个节点的真实负载去做波动的就是如果它低负载那我可能会一直往上超超到你设置的这个上限如果它水为上来的话我们会把水就是把这个超卖调回去刚刚的问题是EHPA是面向预测的然后对于突发流量不可预测的突发流量怎么做因为刚才齐明老师说了我们有HPA的策略去兜底就是EHPA会包着HPA的定义的部分所以不会有问题您要老师就是刚刚那个资源模型上一直都是拿着CPU的去讲然后在实际情况下比如说内存的你怎么去预测因为内存一般有就是有没有就是没有它是一个就是一个硬资源它不是像CPU这种可以做实验面轮转您说的是在弹性的场景还是在超卖场景弹性还有做资源预测的时候是做资源推荐还是做资源预测推荐然后预测的时候因为那个情况不一样因为如果要是客户发过来发起了流量这个其实不太好预测或者说有一定的拼差如果要是自己能控制的比如类似像大树狱这种然后倒是很好预测在弹性的场景中内存的话是不太适合用来用来做指标的因为内存它有很多的cash对 所以说我们Best Practice是很像的时候一般配CPU包括它的QPS然后在VPA场景中我们一般会计算内存因为那个场景它还是能得到一个相对靠谱的值在哪个场景在VPA就是规格推荐我们会我们刚才有一个能力叫做规格推荐它会去推荐合理的CPU和内存的配置那么内存的配置的话我们是可以通过规格推荐来去给到一个推荐值的它是根据你过去比如说7天的一个内存的使用来给到一个值比如说像内存这个内存的使用率上应该怎么样去算它的使用率呢因为内存是预申请的它一旦申请到一定值之后它没有主动进来的意愿对但是那个值其实就是它应该配的值了不能抵御它它要拿那个理论风值去做那个就是那个预测的那个说一点是的我来补充一下就是内存的预测其实挺难这块我们很多时候是基于超卖去做的就是很多业务它申请的内存它就不会交还给操作系统了所以它站着就是站着了但是这里面真实的应用的比如说coblate会按working set去做它会用就是usage然后去减去它的active file去算它真实的占用那我们也会用类似的这种公式去计算它的业务的真实如果你申请了但是没用那这个时候其实系统是可以回收的那我就可以去做超卖拿那个比如说RSS那些指标是吧对 类似这种比RSS就是你看coblate的它的指标我们用同相同的指标去做不好意思 还最后一个然后我的想相对存这种因为我理解就是它是个硬资源然后不太好做的情况下是不是可以基于那个压侧数据相同资源它能承受多少的OPS然后基于这种QPS进行服务的承载能力的就预配制然后这种情况下是不是就能规避这种呢对 业务来说通常在腾讯内部有一个资源推导模型就类似于你说的方式是说我去预估一下我这个业务生的QPS是多少然后基于这个QPS去压侧然后这个时候推导出来的这个资源使用率就是真正的业务需求但是你真实线上会不会用到QPS到不了那可能就不达标它还是要往下缩明白好 谢谢老师那个时间还有吗那剩下的话我们可以剩下到这边来交流好 谢谢大家