那那个时间差不多也到了然后我们就正式开始吧首先欢迎大家来到今天这个topic然后今天这个topic我们主要会介绍我们是如何构建生产级的HPA的这里面主要会包括我们使用了什么样的智能算法以及我们是如何降低自动扩营的风险的首先我们先来预览一下这次topic主要内容首先我们会简要回顾一下KBUS的HPA然后我们来看一下就是它目前存在哪些局限性使得我们难以在生产上去大规模的使用它之后我们会来介绍一下蚂蚁内部是怎样构建生产级的HPA系统的最后我们会简单介绍一下capacitycapacity也是我们近期新开源的一个云原生质能容量的项目我们会一起来看一下capacity能够怎样把我们内部的一些方法论实际应用到任何一个开源的KBUS机讯那么在正式开始之前先请允许我们做一个简单自我介绍我是朱子秋 我来自蚂蚁集团目前是在云原生科技负责各类云原生平台和产品的一个建设目前我主要是关注弹性调度和多级群的领域然后我也是开源爱好者近几年陆续贡献过一些新CF的项目然后这位是郭亦如他是蚂蚁基础设施容量团 智能容量团队的他在容量领域有非常丰富的经验也亲身参与了蚂蚁大规模生产容量系统的建设那最后我们都是capacity这个项目的Founder如果对这个项目有任何问题欢迎大家随时都可以来找我们好 那么下面就进入到今天的这个正题首先我们先来简单回顾一下KBIS的HPA相信这块的话其实相信大家既然是来听这个厂子那应该对这个东西其实都比较了解那我就不会做太多详细的介绍那我们可以看到HPA的原理还是非常简单的它的本质上其实就是实时的去通过指定一个监控指标然后去折算你这个对应的当时这个监控指标对应的一个你需要的一个副本数然后最后它会通过Scale API的方式去对你的工作负载去做一个实际的擴充容那可以看到它的核心算法其实就是根据监控的这个目标做一个简单的折笔计算是非常简单的那么这里我们其实也不难发现它的一些矩线性这些non-production grade size首先就是说它这里我简单列举了这个4点首先它是一个纯响应式的流程也就是说它是发现我这个指标现在已经不满足我的期望了这个时候我才会开始去调研它的副本数那么它天然的它是有一个制后性就是一个事后的一个动作第二点就是它的算法刚才也看到了它是一个非常简单的折笔算法这里它其实也就预设了说我的副本数和指标它一定是一个严格的现行关系这个时候它计算出来的可能才是相对比较准确的这样一个值那么这里其实就是比较理想化的但我们在现实生活中现实的生产当中其实我们的应用它的流量它的容量等等非常复杂它可能并不一定满足这样的一个现行关系那么第三点就是它的我们知道就是擴缩容在生产环境其实是一个比较高位的别人尤其是缩容一不小心我们生产环境可能就给你搞挂了所以在这个时候其实我们非常需要去控制HPA它的一个风险那么社区HPA其实在这上面做的事情是比较有限的就是目前来说比如说它是提供了这个速率的一个控制那这个其实对于一些更加严格对于稳定性更加要求更加高的环境来说其实是不太够的那么最后一点其实就比较忍者见人了就是HPA它其实是K8S一个内置的一个组件那有些人可以觉得说我这个HPA开箱举用挺好的但是另外一方面的话它其实相当于跟你的环境的K8S其实就绑定在一起了比如说我希望用新版HPA的一些功能或者说我想要对HPA的行为去做一些定制或者做一些扩展那这其实是很困难的所以从上这些点我们在马也内部做谈应扩作用的时候其实当时也是做了很多的选心然后但最后没有采用直接用社区HPA的一个方案那么我们的HPA最后是怎么做的呢然后到底有没有做得比它更好呢那下面有请我同事归入来为大家介绍在马也我们是怎么落地HPA的大家好我是来自马也集团的归入刚刚我的同事已经跟大家介绍了我们社区HPA的一个基本原理以及它的一些局限系在这里我主要是给大家介绍一下我们马也是怎么克服这些局限系并在我们生产环境落地的在此之前我先补充两个我们碰到的一些困难第一个是我们马也在线应用的幼流量以及它那个幼模型比较复杂我们的幼流量可能有RPC消息等等各种各样它的幼特征可能有的有规律有的是没有规律的第二点是我们马也的一些弹性速度相对比较慢没办法满足我们快速弹性的一个需求收陷于我们的一些容器创建还有一些应用的一些启动速度等等导致我们可能在经典PASS的一些链路扩容速度可能会达到10分钟一个级别因此基于以上原因我们没办法直接在我们马也内部在生产环境落地社区版本的HPA因此我们就基于我们社区HPA的一些设计思想加上我们马也内部的一些独特的技术形成了我们自己的一些解决方案接下来我看一下我们自己的一个解决方案这个是我们整体的一个解决方案我主要分成了四个模块第一个是我们的一个采集模块包括我们对接了我们自己马也内部的一些监控平台一些原数据平台这个采集模块可以采集到我们在线应用的一些指标数据包括流量RPC消息还有一些CPU还附稳数等等一些原数据信息这些历史数据信息会发送给我们一个数据分析的一个模块我们数据分析模块会对这些数据做进步的处理包括数据清洗特征提取以及我们对这些数据通过我们的算法做一些预测我们会对这个结果做进步的验证最终产出我们在线应用的一个在线应用的一个画像我们的画像简单来说就是在某个时间点我们副本书的一个描述信息由于我们容量场景的复杂性我们在不同的场景会产出不同的一些画像比如在日常的一些场景对于一些有规律的应用我们会产出周期性的画像对于那些没有规律的可能会有一些流量秃动场景的我们会产出一些应急画像这些所有的画像最终会发送给我们的一些流量管控的一个平台画像管控的一个平台我们画像管控的平台会对这些所有的画像做进步的分析以及决策最终产出我们最终真正生效的一个画像在决策生效的过程中我们也做了一些严格的一些技术风险防控包括我们的挥动变更我们的主动风险发现以及我们的准入变更等等我们生成最终的一个生效画像之后这个会下发给我们的一个执行模块我们的执行模块会根据画像的一些描述包括我们的卡达夫斯坦败等积极数的一些状态然后来做最终的一个变更这个变更既包括了我们的一个状态变更也包括了我们一个一个坦性的一个伸缩的一个操作当我们发生变更之后其实我们的在线运用的一个运行室已经发生了变化我们的数据采集模块会进行下过的采集然后分析等等接下来我们来看一下我们蚂蚁HPA区别于社区HPA的一些主要特点我先来介绍一下我们的预测式的一个算法那么我们为什么采用预测式的算法而不是社区响应式的算法这里做一个简单的介绍我们可以看到左边的这个图是我们响应式算法的一个图而右边的图是我们预测式算法的一个图我简单介绍一下我们图中的一些元素我们上边绿色的线是我们流量的一个曲线是一个波动的是一个非常有周期性的而我们黄色的矩矢状的线是我们副本书的一个曲线下面绿色的线是我们平均CPU水位的一个线而黄色横着的那条线是我们期望的CPU水位的一个线通过左边响应式的跟右边预测式算法的一个对比我们可以很明显的发现对于响应式算法它的扩张容其实是之后于它的流量反而变化的也就是说它流量反而变化之后它才感知到这个变化然后再去扩张容然后可能在它感知变化到扩张容操作这个成功之间有一个盖谱这个盖谱可能已经产生了一些容量问题但是对于预测式算法来说它的弹性伸缩是先于流量方向变化的因此它更加贴合于流量的那个曲线在流量上来之前其实我们已经提前扩容第二点是我们响应式算法可能很难去控制我们的一个吸油水位在我们期望值之下因为它有一个延迟在这个延迟的时候可能它已经打破了吸油水位然后打破了之后感知到这个变化然后把它通过扩张容的方式然后把它又控制在水位之下然后再打破再控制就这么一个过程但是我们预测式的可以看到它基本是控制在我们期望的吸油水位之下的接下来我们来看一下我们的一个基于流量驱动的预测模型我们为什么要基于流量去驱动容量这个主要是因为有几下几点因为我们知道我们知道我们的吸油水位其实是与流量息息相关的我们通过预测流量可以相对于预测吸油来说就以下几个优势吧第一个是我们的流量相对更靠前一点我们的流量是先发生变化的然后第二点是我们的容量指标可能相对更加复杂一点但是比如我们的CPU还有Maverie 还有IO等这些指标可能会受各种因素影响但是我们流量指标相对来说可能更容易获取而且更简单一点与我们的生活作息也息息相关也更容易预测因此我们就设计了这面一套基于流量驱动的预测模型主要是分成了三个小的一个模型第一个模型是我们的一个流量预测模型我们知道我们在线应用经常有多种类型的流量RPC 消息 IO等等这些流量其实是具有一定关联性的我们单纯预测其中一种流量很难准确地描述我们未来的一个工作负担情况因此我们把所有的流量相关的一些流量类型做了一个建模并且同时预测我们未来多种流量类型的一个时间序列第二个模型是我们的一个CPU评估模型我们把所有的一些流量类型跟我们的CPU还有我们的CPU利用率还有我们的副本术等等建模最终来评估我们未来对CPU消耗的一个预测第三个是我们的一个角色模型我们根据我们对CPU消耗的一个预测在结合我们目标水位的一个控制等来生成我们期望的来生成我们期望的一个这个在线应用的一个最佳配置这个最终转换成的是我们的一个副本术接下来我们能看一下我们的风险防控的一些能力我们在蚂蚁的生产环境落地我们的HPA其实离不开我们严格的一个风险防控我们先来看第一点是我们一个多级弹性伸缩的一个能力我们多级弹性伸缩我们定义了多种泡的一个状态第一个是online是表示我们正常提供浮的一个状态而cutoff是表示我们流量摘除的一个状态而standby是我们表示我们自圆tron的一个状态通过这多种状态之间的一个组合以及它们的一个转换我们可以一方面可以提升我们弹性的一个速度另一方面也可以与我们一些混布的一些技术结合来提升我们的一些自圆利用力第二个是我们灰度变更的一个能力我们的灰度变更与通常的灰度变更有点区别就是我们引入了我们cutoff作为一个中间状态比如我们要缩容一批机器我们会先把这批机器先按照p次把它分批转换成cutoff状态然后我们观察一段时间假如说没问题之后然后我们再把它真实地缩掉那么我们引入cutoff状态有什么好处呢其实第一个是我们cutoff其实就是流量摘除了我们可以模拟泡得被真实删除的这么一个状态然后我们可以观察然后另一方面我们假如说发现有问题之后我们可以通过快速的状态回滚从cutoff变回online这个可以实现秒击的一个回滚第三个是我们风险检测的一个能力我们支持一些主动被动的一些风险检测我们通过巡检在变更期间我们通过巡检我们应用的一些CPU水位爆错异常信息等等监听我们一些相关平台的一些异常事件可以主动发现风险然后即时回滚接下来再讲一下我们HV的一个扩展我们在蚂蚁内部有一个分时调度的功能那么什么是分时调度其实我们直到经常开车的同学直到炒异车道炒异车道就是在它会根据交通的一个情况再不能实验断安排它那个形式方向是不同的形式方向而我们分时调度其实也类似是把同一份资源在不同的实验点分配给不同的使用者这里的分配并不是一个简单的扩展操作而是我们HV内部的一个online跟snapel之间的一个状态转换比如我们PED上这个图是我们蚂蚁内部日常分时调度的一个场景我们可以看到早上7点的时候其实我们蚂蚁内部有一个蚂蚁森林我们早上起来可能第一件事是先收拾波能量所以7点的时候有一个高峰然后在过了7点之后早上之后可能我们流量会慢慢下降到一个比较低的水位这样资源就空现出来然后我们在蚂蚁珠宝里面有一个蚂蚁基金它是在下午3点的时候有一个流量高峰正好与蚂蚁森林相反它上午的时候是流量低峰3点的时候流量高峰这样我们就设想我们可以把同一份资源在早上的时候自动分配给蚂蚁森林使用在下午的时候让它从蚂蚁森林在同罗给基金使用通过我们蚂蚁的日常分时调度以及我们大宿的分时调度可以为我们公司大概日常到大宿会节省几万块到几十万块的一个资源好 我的介绍主要到这里接下来我同事会为大家介绍我们蚂蚁HP在我们开源的卡帕斯地上是怎么实现的那么下面就到了大家最期待的开源实践环节让我来介绍一下我们在开源当中是怎么做刚才那些技术的现在简单介绍一下卡帕斯地这个项目然后卡帕斯地这个项目它的定位是一个云原生的智能容量解决方案目的是帮助大家以一种智能的无风险的方式来做K8S容量层面的叫门增箱这里无风险它其实也是一个比较重要的特征因为现在很多社区的项目可能对智能可能大家都有一些关注但是对于风险 对于生产级的应用这一块可能相对来说是会比较欠缺的这个项目是今年6月份刚开源的所以比较新所以可能大家也不太了解所以也没关系那么今年第一个版本主要是包含了整体架构还有空行控制的一些能力那么近期我们将发布0.2M版本会主要包含智能算法相关的能力这块目前其实弹码都已经计较了然后再做一个最终测试的这样一个阶段所以这次topic其实相当于也是会提前剧透这个版本的一些技术内幕所以在座的各位其实也是整个社区当中第一批了解到这块信息的好那么目前来说呢capacity的项目提供了一个核心的能力叫做IntelligentHPA我们后面就把它简称为HPA那么顾名思义HPA它其实就是一个智能版高级版的一个HPA那么它主要是有下面三个特征首先它第一个特征是智能性这边其实集成了我们蚂蚁在内部大规模生产时间当中打磨出来的一些智能算法那这些算法或许其实也都是完全开源的那么第二是这个技术风险那这个其实也是蚂蚁的一个特色因为大家有了解的风险可能知道蚂蚁这个技术风险的文化就是我们对这个生产环境稳定性的要求非常高因为涉及到一些金融这块是受到一些金管要求的所以这里面其实也实现了我们在这个生产时间过程当中涉及总结的一些风险控制手段那么最后HPA它做一个开源的组件其实我们在涉及的时候就会把扩展性放在第一位那么在等一下片子里其实大家也能看到就是我们会我们涉及一套非常容易去扩展和自立架构那这样的话其实会方便大家在按照自己的需求去对它做一个落地使用那么下面我们就来看一下就是刚才我同时郭亦如给大家介绍的这些方法论我们是怎么样去通过卡帕斯也去给它实际落地的那么首先我们来看最关键的流量驱动的复文书的预测算法刚才相信大家郭亦如也给大家介绍过了就是为什么我们要使用流量驱动这里我可以再简单总结一下因为这块确实比较重要就是我们之所以不选择说直接去对CPU做一个预测而是对流量做一个预测那其实是因为我们对于在线运用而已流量其实是它产生CPU波动的一个根源我们现在有流量然后再有CPU这样一个波动所以我们预测的流量会更加的就是一个更加提前的一个工作并且流量相对于CPU它更容易去做预测因为CPU会受到各种非常复杂的环境因素的影响但流量跟我们的生产生活是相关的所以这里我们会有一个流量驱动的这样一个算法那么这个算法它主要的目的是什么呢它主要的目的是找到下面这个函数那这个函数它的输入其实就是说我当前的流量以及我当前的副本书我们就给它处理一下它的输出就是说在我当前流量和副本书的情况下我每个副本它平均的资源利用率会是多少这里我们通常就比如说是最常见的就是CPU利用率对吧 会是多少那么所以这个时候我们首先要去给它设定一个弹性目标这个时候我们设定的弹性目标其实就是这个资源利用率那这个其实是比较直观的对吧 因为我们为什么要做HPA呢我们是要去控制它的资源我们说我们需要让它的CPU能够达到多少的水贵而不是说我们是要控制它的平均流量现在多少对吧 那这个其实是比较符合直觉的但是这个模型它的最独特的地方就在于说虽然我的目标它是一个CPU水位但是我在做弹性货送的时候它其实不是只看CPU水位这也其实就是和K8SHP一个非常大的一个区别那么这个时候它其实是会做这样的几个事情首先它会把历史的流量和历史的资源利用率和历史的副本书的情况收集起来会先通过一个性性的模型去建立这三者之间的这样一个关联也就是说通过这个模型之后我们可以知道在我有多少流量的时候以及在这个有多少个副本书的情况下我的资源利用率会是多少也就是说通过这个之后我们能够初步地找到下面的这样一个函数但这个函数它其实是有缺陷的就是说我只考虑了流量对CPU的一个影响这里我以CPU为例就是Resource但其实我们知道刚才说到Resource这个东西它其实是一个环境敏感的东西很多时候比如说我这个应用这里其实我举个很简单的例子比如说我的一个应用它可能每天晚上比如说零点的时候它自己内部有一个定时任务会开始去跑一下比如说做一些这个事情那这个时候其实它没有流量但它CPU会有一个上升所以这个时候我们光通过这个模型其实没有办法补收到这个特征的所以最后我们会给它叠加一个残差的模型然后通过这个模型我们可以把一些其他的一个信息输入进来那目前来说我们现在只考虑时间那后续的话其实也可以扩展成就是甚至一些机器的一些型号的信息下等等等等那么这个时间就是刚才说的比如说某一天零点我的这个CPU会有一个兔子那通过这个模型它能够找到这个特征然后去修正这个函数那么最后达到效果是什么呢就是对我这个函数来说比如说我每天晚上零点的时候我同样是这个流量但是它在零点的时候给出来的这个推荐的这个副本书它一定就会更高因为这个时候我知道它的CPU利用率会更高所以说它的这个sauce它要来源就是它有这个同时考虑流量然后资源利用率还有副本书那目前在这个开源版本的时间当中呢这个信息的模型我们用的是LAST INNET然后残差模型就是LIGM然后这两个其实都是传统机器学习的方法也是比较轻量的就是不需要通过CPU通过CPU我们就能很快地去做个机身但是这个东西同样也是可以优化的就是说这里的这个信息模型和残差模型其实它不是一定要使用这两种模型其实我们可以通过任意的模型其实都可以去都可以去做你甚至可以把它替换成生物学习的模型所以这里其实可发挥的空间是很大的就是大家也可以自己去尝试的去做一些探索好 那么我们现在有了这样一个函数了对吧 那这个时候我现在想要得到我预测的一个副本书我现在已知我的期望的资源是多少比如说45%然后我想要得到这个那这个时候其实我只需要预测未来的流量就可以了这个就回到了Traffic Driver这个事情上面那么接下来我们就需要做一个流量的预测那流量预测相对来说就没那么复杂了就比较直观了它其实就是转化成了一个失去预测的问题就是我都要这个流量去做一个失去预测那这里我们来看一下那目前在卡帕自己使用的是我们内部研发的一个深度学习的失去预测模型那这个模型它有两个比较大的特征一个是它非常简单清亮因为现在其实说到深度学习其实大家可能就第一个想到就是大模型对吧 可能说我需要成版上签的GPU去给它做一些训练那如果是这样的话其实我们这个HPA给它节省的资源可能还不够你训练的所以这个时候是得不尝试的所以我们希望HPA用的这个模型它尽量都是清亮的所以可以看到这个模型的结构其实也是比较简单的它会对于你的APP还有流量数量去做 embedding那么之后它会通过 fully connected layer去做 a prediction所以这边可以看到它其实没有很复杂的模型结构没有所谓的transformer这些东西在里面所以说它的模型结构简单所以这也就导致了就是说首先它大小很小就这里举个例子就是说假设我现在是12个点预测12个点那么以10分钟精度为例的话其实就是2小时预测2小时那这其实也是一个比较常见的预测的一个pattern那这个时候这个模型的大小甚至不到1M甚至你说夸张你把它放到coffee map里就可以那么同样它训练成本其实也比较低就比如说我用我Mac的这个CPU去跑一下那其实一个APP就1分钟那差不多我用CPU去跑的话可能也跑个一个小时可能也就能训练出来一个可以用的这样一个模型那么它虽然它轻量但是它的效果还是比较好的那这里其实我们也是用我们内部的实际的生产的流量去把它跟其他的模型去做一个对比可以直观地看到就是说它的这个效果其实是好于常见的这个比如说地平啊nbeats啊这些持续测算法的那么这里其实不是说它这个东西就比那些就是它在持续测上的效果就比这些外面开源的或者是好这里其实它在于说它在这个浴测生产流量这件这件细分的这个事情上面会做得比这个其他的模型更好所以这个是它的一个主要特征那么通过刚才这两个东西介绍的我们可以给大家串一下就是我们来看一下最终在capacity里面我们怎么具体地去做一个负本这样的浴测那这也其实我们就能看到蓝色的这条链炉是一个离线的链炉这也其实就涉及到刚才这个深度学习模型的training因为我们知道深度学习它是要training的那么training这件事情其实不需要不需要经常做对吧 可能你说我把这些流量量的数据把它供动下来就是说它的重点在于说我找到我流量的一个规律对吧 以及一定时间内的这样一个趋势比如说我可以半个月甚至一个月可能我训练一次也是能够满足要求的那么这个黄色的部分其实就是在线链炉就是我的实施预测的时候我需要去做的事情那这里会看到它首先会做一个流量的预测对吧 这里的话其实就是做一个模型的推理它是一个非常轻量的一个过程那么之后它会把刚才我提到的资源的历史副文术的历史然后连同我在HPA设置里面配置的资源水源目标一起放到就是第一个提到Rapkin estimator的模型里面那最终它做一个简单计算就能得到我预测的副文术所以这个是它整个副文术预测的这样一个工作流那么我们知道就是我们光用预测其实是没有办法满足所有场景的因为这个世界上总有不能预测的东西那么我们会有一些突发的一些流量或者说我有一些人为的人工经验对吧 我希望它就我人提前知道的时候那个时候我需要多少副文或者怎么样所以这个时候其实我是需要有多种规则组合的那这一的话其实我们就提供了这样一个按照有优先级的多种弹性规则组合的这样一个能力那这是一个具体的例子就是左边是HPA压抹的这样一个规则的这样一块内容那么在这里面可以看到我们有我们配置了三条规则那么前两条规则其实都是由算法产出的动态规则那么第一个是预测算法的规则然后第二个是响应算法的规则那他们两个共同服务于CPU水位利用率45%这个目标那只不过前者呢他是通过刚才我提到的这个Traffic Drive的这个模型去做个预测然后得到的这个副文数那后者呢是通过就是跟K8SHPA一样的一个算法去实时的去看现在的这个水位然后来计算的那这里可以看到它优先级是一样的所以在优先级一样的情况下呢就是谁拿去谁那么在这种情况下其实我的这个Reactive它其实就起到了一个兜底的作用也就是说当我的这个预测没有就是我的预测没有在没有把这个水位控制好这个水位我水位已经超出来了那这个时候我的这个响应区它就会兜底的起到一个保护的这样一个效果那么这里第三个规则呢是一个就可以看到是一个人位是一个Chrome的规则那以这个应用为例吧就是这是一个应用那刚才提到就是说这里是可以预测到的那么这里是没有预测到的那么通过刚才那两种组合呢我们可以完成这样的一个一个父母说的调整那么还有一个情况就是说我这个应用比如说我现在它的0到6点我就是停幅的我就是它都没有流量那这个时候我再去看它的CPU利用率其实也没有什么意义因为这个时候我的应用它就不需要提供服务那这个时候我其实完全可以把资源全部出让出来去跑一些比如说我的理解任务那这个时候其实我就设置了这个Chrome的这个显示的这样一个规则让它在0点到6点的时候我就给它缩零那么它的Priority是更高的所以我们可以看到在这个0点到6点Traffic Ops的这段时间其实我是通过Chrome的算法我可以让它把这个父母数调来带零而是从6点开始我才有一个就是会进入到一个算法生效的这样一个阶段那么通过这个这几个规则的配合呢其实我们可以就是非常灵活地去试图多种这样的一个场景那么接下来看一下就是说它是怎么实现刚才这个过一如给大家介绍了这个多阶段灰度这样一个能力的那灰度其实比较简单我就不提了因为灰度的话其实它就是在内部控制一下这个或是说这样一个顺序或者说是一些时间等等那多阶段这个事情它就比较有意思因为我们知道社区HPA它去控制这个父母数的时候它其实就是通过Scale API去做或是说融了那这个时候它的这个或是说融是完全交给这个我close来做的但是当我需要做一个多级或做融的时候它就不一样了因为这个时候所以在这里呢其实我们把它简单分成了下面三个步骤就是首先是做Pode排序然后是状态变化的执行然后最后是实际的这样一个或做融那么这里呢因为我目前是靠Tof因为Standby的话这个资源出让它是需要一些这个底层Agent的支持的这块的话目前还没有开出来所以我们这里就以Cutoff为例但是它的流程是一致的那么首先我们需要做一个Pode排序为什么要做Pode排序呢因为当我们在Scale的时候这个时候是WalkerLode去控制的Pode的缩容顺序但当我们要去手动地去给它做一个状态召唤的时候我们就需要自己去控制顺序了那这个时候我们需要我们的这个排序和WalkerLode实际的缩容是匹配的所以我们目前是内置的一些KBS常见的就是内置WalkerLode这样一个排序的规则确保就是说我们执行这个Cutoff的时候一定是先Cutoff那个WalkerLode接下来会缩容的那个Pode那当然我们也提供接口就是说用户它可以自己去对接自己的WalkerLode去控制自己的这样一个顺序那么对于一些比较高级的WalkerLode大家可能知道就是现在视频上有一些WalkerLode它比较高级我可以去指定它先缩容哪个Pode那这个时候其实我就可以完全自定义我的一个缩容顺序了那么第二点就是说我现在开始进行一个实际的状态转换操作那么这里就是栅流那栅流我们知道在社区里其实我们默认的是用Redness Gate去给它实现的那这个的好处就在于说如果你是用比如说Country Manager去然后通过原生的Service Ingress去控制你Pode的流量的话其实直接通过这个它就能够直接的去做一个实际的这个摘挂流量这样一个操作了那当然如果你是通过一些比较传统的方式去做的话我们也提供接口就是说你去对接你自己的这个摘挂流量系统你去对POD做一个摘流挂流那么最后这个Scaling就不说了它就跟社区是一样的它就是在最后Scaling的时候会通过Scaling API去做实际的扩作所以如果你不需要状态转换的话那它和HPA是一样的就是只要你的WalkerLode是Scaling API它就可以做HPA好 那么最后我们把所有东西给它全部汇总起来就设计成了这样的一套架构那么可以看到在这里面我们其实是把HPA做后并且拆成了三个板块三个模块就是HPA它本质上其实就是做了这三个模块的事情就首先第一个是控制面那这里就是HPA control那么它提供的HPA这个对象其实就是用户实际感受到的就这么一个对象所以这样的话其实用户在用HPA和用HPA其实也不会有太大的这样一个感知上的变化那么它其实是把这个决策的这个事情和执行的这个事情做了一个粘合那么第二个就是决策那这里就是水平画像的这样一个控制器那在决策在KBS里面它其实就是去做一个算法就大家可能知道看过代码大家可能知道是replicate calculator那么在这里的话其实我们就是对接了我们自己的算法那么在这里用户其实也可以去通过自己的算法去生成它需要的Portrait然后去控制HPA control的这样一个扩展成这样一个决策那么最后就是Execution执行层那么这个在KBS的HPA里其实就是Scale API那么在我们这里呢其实就加入了多阶段的这套逻辑所有多阶段相关的扩展比如说这个扎挂流对吧然后Scale的这个逻辑其实都可以通过扩展这个replicate controller去给它做一个控制那最后的话呢我们还提供了这样一个matrix provider server的这样一个东西因为用KBS的HPA的话大家也知道KBS有matrix API这个东西对吧那么它是提供它是可以封装掉这个底下监控系统这样一个接口我们不需要去直接对接普通标识但我们可以通过matrix API去拿到我们想要的API但是在这个我们当我们引入了更高级的算法之后其实我当前的这个matrix就不能满足我的需求了我需要历史的matrix那这个时候呢我们其实就设计了一套就是跟这个matrix API基本上是一样的这样一个接口但是我们能够让它通过matrix API的形式去拉到历史的指标那这样的话其实我外部的一些算法它不需要去对接普通标识或者对接什么其他的监控系统它通过我们提供的这个matrix provider server通过一类似于matrix API的方式就能拉取到它想要的这个监控数据了所以这就是整个我们这样一个架构好 那么有关这个HP的介绍呢大概就在这里那么最后给大家同步一下我们后续的一个计划大概会分这么几个方向首先在质能性上我们会引入更多的这样一个算法就比如说刚提到就是我们通过我们现在是通过这个想一试的算法去做一个DODI对吧 但是想一试其实它还是质厚的那这个时候我们能不能通过一些实需检测的手段去实施的去发现我们这个流量是不是有一个恶化的趋势呢对吧 那这里其实就涉及到一个Burst Detection这种东西那么还有一个呢就是分层识别这块那分层识别这块呢其实我们后续会把刚才贵入给大家提到的就是这个自动的识别和资料给它做进去那这样的话呢它通过这个多阶段回渡它就能实现这样一个完整的避换那之后呢我们也会做一些可实化的情况那些事情比如说引入dashboard之类让大家能够更加容易地去使用起来那么最后呢也就是说这个项目它其实不仅仅是会包含HPA它其实也会把我们内部的一些其他的一些容量能力给开认出来就比如说刚才提到的这个分层调度对吧 所以也进行大家保持关注好 那么今天的这个内容就到这里了然后这里有一些我们提供了多个渠道大家可以按需扫码吧然后国外有人我们也提供了slack的渠道然后有什么问题的话可以有一两个问题可以回答一下我觉得有几个问题就是我们在去控制控制我们的work load去缩容和扩容的时候是怎么样去handle的因为我们知道deployment的代码不在我们的这个项目的控制范围内嘛这是第一个第二个是说我们在控制流量的时候当我们比如说把它的redis gateshutdown false的时候有没有可能会被其他的控制器给改回来因为它的其他的比如说LB的控制器有可能它自己会控制这个流程这两个问题好 我回答一下第一个问题是一个很好的问题就是说确实就是说对deployment因为deployment它本身的这个缩容行为它其实也不是一个能够百分百确定的对吧 有的时候它也会有点偏差对所以如果你是需要一个比较稳定的这个多级多级多级缩容效果的话那我们通常会推荐就是你去使用一些缩容顺序比较稳定的就比如像stiffle set对吧 它是从后往前一定按这个顺序去做的对吧或者是你自己有一些我hello它的缩容顺序是稳定的那deployment的话目前我们是虽然k8s的代码不在我们这里但我们可以引用它的代码对吧那我们内部是其实集成了就是k8s那个replacasset它缩容的这个算法的一个逻辑就是我们会预先演算好就是说在目前这个状态下它会怎么缩容而且这里其实还有一个有一次点在于说因为我们是先dialo在缩容的对吧那么dialo的这个plot它在replacasset的优先级一定是最高的因为我的not ready plot一定是最纤索的所以通过这个情况我们其实也能够在一定程度上保证我们的缩容能够按照我们期望的顺序就是它肯定不会缩一个online的plot对吧它会先缩一个not ready的plot那第二个问题的话呢这个比较好回答就是这个ready scale其实我们自己注入的所以其实我们会控制对你好就是刚才你讲的那个就几种一种响应式的还有预测式的还有就是zoic的crown的对吧我看见有个配置但往往现实当中的这种流量它是很波动式很大的嘛不同业务的特征不太一样嘛那这种怎么去配啊我看三种你是这么去配对吧但实际上这种配置我感觉还是挺难的怎么配一个合适的这种策略对这个其实从通用的来讲的话就是如果你没有什么人工经验的话就对于一个通用的引用那可能就是我因为你想你用k8shpa的时候其实你不需要考虑这个问题是因为它只能配一种规则对吧那这里其实我们也没有引入太多的规则所以在这个情况下其实一种推荐的做法就是说你先给它配置一个预测的规则就是说其实预测的规则它就基本上就能够handle正常你一个再先用的场景对吧它的这个流量就是它每天有规律这样一个波动然后你去给它做一个预测那之后对于不可预测的部分你再配置一个响应式的规则去给它做一个dody就可以了就是刚才我那个例子可能会比较因为会需要讲述各种场景嘛会比较复杂一点但通常来说你的应用它也不需要配置就这么复杂的规则它可能一个预测是加一个响应式就能满足绝大部分的一个情况对 就是响应式给预测式做个dody然后基本上预测式它就是为了cover所有的情况而产生的对你好 我有两个小问题第一个问题是说刚才你提到就是不同的策略之间它是有dody逻辑的意味着你的资源荣誉可能是有一定荣誉量的那这个时候如果说多服务都因为这个荣誉带来的那个就是多余资源占用很可能说我缩容之后下次因为资源有限嘛我怎么保证我能拿回来这部分资源因为可能多服务资源竞争这部分资源这个是第一个想了解的部分怎么去处理这种情况vp应急资源是有限的第二个是说因为这个本身这个项目是capacity因为想着是说我们在生产时间中通常HPA和vpa可能都是集合着用那么我们在这个整个项目中有没有这段话有一些相关的一些联动过考虑就比如说如何去平衡HPA和vpa之间的出发时机和应用场景好 就是这样就是第一个问题的话就是你问的是多级的时候它怎么确保我贵滚的时候它一定还有这个资源那这种话其实对于cutoff不需要考虑这个问题因为cutoff我只是去做摘留对吧 我的资源还是占用在那我们资源没有释放它是一个纯稳定性的一个优化你说的可能在于说standby就是在我出让的这个状态下它怎么去确保这个资源那在这个情况下其实我们在myNable其实是通过一个分时调度这样的能力去控制的就是说因为在这个时候因为我们身上就提前会有算法计算得到说我现在不同的应用它在不同的时间段它的一个资源需求那么我们会把这两个错开的应用放在同一个资源的池子里那确保说我这个应用在缩掉的时候我那个应用它其实不会有太多的资源增长去把这个资源重新占用掉那当然你说这个情况确实当我需要更大的提高资源利用的时候它可能也会存在那这个其实就是它的一个代价就是说我利用了资源那必然会对我的这个稳定性造成一定的影响就是说这个时候我在重新去扩容的时候它可能就会扩容得慢一点就它可能需要重新去找个资源对吧刚才提到你这个策略是有冤极的我想知道就是比如说你个不同服务间就比如说我需要五千盒它需要三千盒但是对它来说对我来说可能我的冤极更高类似这种服务间这个目前暂时没有因为就这个的话可能是需要有更高更上层的一个混布系统去做这样的事情OK然后你说的第二个的话其实你可以关注一下就是社区那个Other Scaling它其实之前也在推一个HPA VPA就是结合在一起的一个Scaling的一个东西就是你可以去看它里面是怎么设计说我什么时候用HPA什么时候用VPA的对那这个项目中有考虑这个项目那这个项目的话目前就VPA这块的话目前还没有个很明确的规划因为这块的话其实能做的事情不多因为现在的话其实都是做一个应用规格推荐那规格推荐其实它的算法没有太多可以发挥的空间对吧 基本上还是以Google Autopilot的那个滑动窗口那个东西为主所以这块的话目前暂时还没有说有一个直接的一个想法对好的那还有问题吗好再问一下就是我想问一下在做除了这个应用它相关周边的一些比如说数据库和Redis它们的一些库座容你有没有考虑在这个范畴里面因为这个流量上来之后可能一些数据库它也需要做一些库座容你真的是个好问题确实这个目前暂时是没有考虑的但我觉得可以作为一个future request可以去看这个事情那如果没有问题的话我们今天这个topic就到这里非常感谢大家