我们主要从这几个方面来给大家分享一下这次的议题我们会简单的先看一下在单击群里面HPA是如何使用的并且它有哪些限制如果我们将单击群的HPA扩展到多级群里面它会带来哪些好处和优势最后我们会详细地介绍在多级群里面HPA是如何实现的我们实现的时候有两种方式一种是集中式的Federation HPA然后还有一种就是分布式的HPA这就是我们今天的议程好的,然后我们先来简单的回归一下在单击群里面HPA是如何工作的那么我们可以看到HPA简单的时候就是去扩展到POD的副本数比如像你的POD运行的业务当请求流量上来的时候你的POD就可以自动地扩展扩展起来去处理更多的业务那么如果当你的请求下降的时候比如像到晚上的时候你的POD可以自动地缩容去减少这个资源的消耗那么它的工作原理就是我们会有一个HPA的这样一个CR然后里面会定义你的给哪一个资源做扩展然后去根据什么指标来决定你的业务现在是什么状态它会每个州去查询来决定你的业务现在是应该扩容还是缩容这就是在单击群里面的HPA的工作原理然后我们简单地看一下这是K8原生的资源然后我们简单地看一下它的这个样率比如像刚刚这里写的Scale Target Reference就是指定你这个HPA要给哪个资源进行扩展那么你扩展中有一个范围比如你最小负本书是1最大负本书是10那么根据什么指标比如这里写的是CPU平均率是50%那么就是高于这个50%它就会缩容低于这个100%它就会扩容它在单击群里面的HPA它的整体的工作原理就是这样子的那么显然在单击群里面它就有一些限制我们来看一看它有哪些限制我们知道一个几群里面资源它不是不可能无限的增加最核心的就是比如我们一个漏的一个节点它的Po的个数比如像K8它默认是110个Po的你不可能在一个一个节点上无限的去创建Po的那么像K8它一个几群里面它的漏的个数它也是不能无限的往一个K8里面加资源那么这个资源当你的这个服务量很大的时候一个几群是没办法存在你的业务的时候你的资源也限制了你的你只能使用一个多群的场景那么还有就是如果你已经使用了这个多几群那么你的HPA就会很多比如我们有客户它就是比如像它有100多个几群它就有很多很多HPA那么它就每个集群都要去处理的自己的HPA资源那么它就缺乏一个统一的管理的HPA的手段那么还有就是如果你的资源一直扩缩容那如果你在这个云上用用的是公共云那么我们也知道这个在云上你的资源都是用钱买的如果你一直扩缩容一直扩缩容它是很浪费点资源所以我们也想在一些贵的云场上让它少扩一点在一些便宜的云场上多扩一点那么我们想这种扩缩容有更多的这种策略来控制它的扩缩的手段这就是单级群里面它一些限制那么如果我们将这些以限制怎么来解决如果我们将这个HPA可以生长到这种跨级群就是我们这个HPA可以跨越级群的边界来自动的伸缩那么我们会带来哪些好处呢最典型的就是我们可以突破这个资源的限制刚刚说了一个单级群它总是有资源限制的那么我们可以突破这个资源的限制让我们的业务可以跨越级群去弹性伸缩对然后我们还可以刚刚也说了我们还可以根据定义去拿去更多的这种调度的扩缩中的策略我们可以有丰富的API去控制它因为我们知道刚刚那个K8的原生的HPA它其实是手段比较单一的如果我们能突破这个边界的话这个好处是显而易见的然后我们HPA是依赖于这个K-Mata我们简单来介绍什么是K-MataK-Mata是一个容器编排的一个开源项目生因CF下的一个开源项目然后它的核心理念我们可以购建一个我们可以使用K-Mata购建一个无限的可以伸缩的这种资源词那么它最重重的最重重的一点就是我们可以让多个级群多个K8S级群它的使用体验就像使用一个单级群一样也就是说你现有的工具是可以不经过任何修改无缝的来使用这个K-Mata并且就可以控制这个多级群那么它这里面几个核心的亮点我也列了一下比如它原生的支持K8S的API也就是意味着你现有的工具是不需要做任何的修改非常的无缝然后它开源中立因为它是托管于CF的然后它避免厂商的锁定比如我们你用了购买了公有云公有云它很多服务它都是必须在它这里使用才能用没办法换厂商你可能就被它绑定了你只能买它的很价格的一些设施然后它一些开箱机用我们K-Mata它是可以比如基于集群故障了我们可以基于故障转移或者是你的应用故障了我们可以将你的应用从一个集群转移到另外一个集群这些功能都是可以直接安装就能使用等等这些丰富的调度策略比如你可以你的业务低缝的时候你是把你的你的应用调度到你的自己的私有云然后当你的私有云你的业务红缝来了之后你的业务可以弹性的公有云业务过去的时候又可以把你的业务调度回来都是一些开箱机用的功能OK我们简单的介绍了一下然后再介绍一下它的这几个核心功能是怎么实现的最最核心的就是我们有一个K-8的APS Server目前的话我们的K-8的APS Server它是附用的是K-8S的原生的APS Server然后它也有一个ETCD这就是意不着你的因为我们知道K-8里面创建资源都是和APS Server交互那么我们现在这个K-8的APS Server它就是一个原生的K-8的APS Server所以你的应用是不需要做任何修改的然后我们这里面也有一些Controller主要是就是做一些业务的调鞋然后最核心的就是我们可以你的资源在K-8的控制品面创建之后我们K-8就可以帮你的业务传播分化到这些不同的集群根据你的策略我们的策略可以支持什么基于地域权重等等还可以支持你的真实负载来帮你调度这就是整体的一个架构接着比较简单如果感兴趣的话可以去看一下K-8的光芬文档好的然后那现在就进入我们的重点来讲一下FederationHPA这是一个跨集群的HPA的定义然后我们先从它的这个API定义里面来看一下我们知道我们要使用一个一个K-8里面的一个CR一个制定义资源我们首先都是先来看一下它的定义因为定义是直面用户的那么我们可以看到整个Federation的HPA它的核心的重点这个Spec里面这几个字段都是引用的原生的K-8s的API定义这就意味着你现在的HPA可以无缝的签议过来我们举个样例可以看到左边就是原生的HPA的定义刚刚有说的比如它是给哪一个副本作扩手容它的最小副本数然后基于什么指标那么如果你现在这种Federation就是跨几讯的HPA那么你可能不需要做任何修改你只需要改一下这个API version非常的简单你的签议成本非常非常的小因为我们知道我们用户其实用户填的都是下面的指标上面我们一般是固定的值上面都是固定的值所以对你来说对用户来说其实是没有任何变化的OK我们这个API定义我们已经了解了我们看一下它到底是如何做到所谓的跨击群HPA跨击群的弹性所以说这里面最核心的就是怎么去跨击群的好我们先看一下我们这里面的组件不好意思我们在Kman的控制屏面的话我们有两个核心的组件一个是Federation HPA的Controller这个控制器这个控制器的话Federation HPA的这个资源作为相应的调节然后我们还有一个Kman的Metrox Adopter一个类似于单几群里面的Metrox Server的一个适配器然后你在用户在控制屏面来创建一个HPA然后创建你的工作负载然后这里有一个资源叫做Propagation Policy就是一个传播策略那么所谓的传播策略就是你将你的工作负载在控制屏面创建完之后你需要给告诉Kman你这个控制屏面要传播到哪些集群比如现在我们在Kman里面落过的三个成员集群那么一 二 三那么你需要告诉Kman你的负载是怎么分发到传播到这些三个成员集群里面我们这个策略里面是比较丰富的比如我们可以基于权重基于工作成员集群的真实的负载情况等等或者是基于地域等等这不是我们这次本次的重点如果感兴趣的话也可以看一下我们的Kman的官方门道好那么还是回到重点我们的HPA创建完之后我们HP创建完之后我们Controller就会Watch到这个资源它就会进入下一个流程我们来看一下然后我们在KmanController里面有一个HPController然后这Controller会Watch到这个资源创建之后它就会去去查询这个Kman的Metrex Otoper这个Otoper它的核心的原理就是会去成员集群去拉取Metrex Server指标因为我们知道我们在K8里面单集群里面需要去安装一个Metrex Server然后去注入一个Apple Version的一个指标就是如果你在单集群使用HP的话这都是必要条件就是必须要装这两个或者是如果你的HP有一些自定义指标比如根据什么HP请求这个数量你也需要自己安装一个自定义的Metrex的一个比如像ProMill COS等等那么这些条件都是在你的成员集群是自带的对然后我们的Metrex Otoper就会去拉取并发的拉取这些指标把它存到这里存到这个Metrex Otoper里面去然后我们的Controller会去根据你的HP的定义去查询这个指标判断你现在整个指标是不是满足你的定义的指标对然后如果你满足比如现在你的指标已经到了你的比如你的CPU到了你的请求的预指就是比如你现在要扩容超过了你的指那么它就会去扩容去修改去修改Department这个副本数修改这个Department的副本数比如你现在是5那么你的现在整个负载是已经CPU很高了然后它就会扩容到10它就会这个HPController就会将这个副本数的副本修改成10那么修改完之后我们Kmata里面还有一个调度器这个调度器就会发现你这个副本数已经变化它就会将你的多余的副本根据你的策略根据你的策略将多余的副本数就分发到这些成员集群然后比如你的这个策略这个选择的是基于权重的或者基于真实负载的那么它就会将你的副本传播到比较小的这个成员集群那么我们整体这样一套流程下来这个HPController扩容你的副本数然后扩容的副本数经过Kmata调度器和你的这个传播策略这样一配合多余的副本数就会在这些成员集群里面去扩容起来而相应的如果你的现在扩容之后你的CPU下降了那么调度器调度器也敢这个Metric Server而这Controller感到你的这个指标已经下降了那么它就会将这个副本数的副本扩容比如给它改成2改成2之后Kmata的调度器就会也感受到这个情况然后配合你的这个传播策略然后将将你的这个多余的副本数就回收起来然后调度器因为它会比如你的这个传播策略选择的是基于这种真实负载的那么它就会将负载高的或者低的根据你的配置然后将多余的副本进行回收就是进行删除对这就是整个核心的理念就是来如何做到这个跨集群的HPA伸缩那我们对比一下我们的单集群的HPA单集群只能在这个集群面进行扩缩容那么我们整个Kmata的HPA它是可以跨越集群进行扩缩缩容对OK OK然后我们在新的版本里面Kmata版本里面就是上个彩发版的里面我们还引入那个Chrome-free的HPA就是我们可以定时基于一个周期定时的扩缩容力的副本那么扩缩容的副本我们是可以选择我们刚刚的FHPA或者是选择你的你的应用那么你只要有用Scale那个紫字园的话都是可以写的然后比如我们可以定时去伸缩定时降低那么都然后这些配完之后调度器和controllerHPA controller同样的原理将你的这个应用进行跨集群的伸缩OK 这就是单集群的HPA的效果那么下面有请江伟同学给大家介绍一下分布式另外一种方案OK好 感谢新鲜同学的精彩演讲然后我这里补充一下就是这个是啥残疾这个定时HPA就是比如说你早上9点打卡那个打卡业务可能会有个流量洪风那就是提前扩的话就可以避免流量洪风造成一个比如说断幅什么的那这个定时HPA的产品就是用在那个产品下面OK那我们对前面做个总结就是说我们实现那个分布式HPA它那个API和那个K8原生的HPA VR那个版本是非常几乎接近的就除了API version好看的所以呢就是用户看到多几群的一个跨几群弹医生说的时候它可以非常小的迁移成本这是它的核心优势就是API非常接近那但是使用的时候要注意一点就是我们可以看到那个它Kamanda是从成员机群拉取数据在控制面做一个统一的整体的计算并且伸缩嘛那么这个有个现在就是它是一个中心式的我们可以看发现所有的操作都是在中心测发生的那这个就意味着如果你的那个并发的弹性规模太大的时候比如说可能200万那个弹性规模那这个就需要非常大的贷款比如说就是我们这里做了一个测算就是500招贷款只能撑在20万port的那个并发伸缩并发那个Metrix Latch和计算那这在某种情况下可能是不可接受的比如说你要出公共语那个Metrix Latch500招贷款一年的花费是很夸张的就那有没有办法是说我不从Metrix不从成员琴拉拉直接在成员琴算算好在在传道控制面做统一的那个弹性说也许做分布式的有没有这种办法呢还有第二个就是刚刚说的它那个相关的所有的计算都是在那个控制面那这些比如说20万port的Metrix这儿缓存着那这个CPU和Memory消耗也是比较恐怖的对那我们就是说有没有更好的方式去做那个比如说Metrix不拉拉计算也在成员琴算然后控制面只是做一个统一的汇聚和调鞋类似的这种分布式的这是更大规模的更小带宽的一个要求呢那我们这边社区是探索了两种方案两种方案都比较接近但是实现是不一样的就是总起来说第一种设计就是通过这个分布式HPA的一个API然后去定义那个管理多个琴HPA的一个API的一个策略比如说优先级管理还是什么其他的管理方法比如说我优先级更高那我可能就先下发这个或者是下发这个把这个HPA给禁掉然后只先谈这个然后再后面再谈这个类似这种优先级的一个HPA管理那这个相关的计算呢可能都是在成员琴琴算了算好了然后他谈心自己的谈不动了OK 我卡玛拉做个调鞋然后在其他成员琴琴琴去把它把那个HPA开启还有谁之种总的来说它就是有一个相关的一个缺心就是卡玛拉需要做就是要控制多个成员琴琴琴的一个弹性的一个行为那所以说卡玛拉有两种两种方式一种是控制每个成员琴琴琴琴琴琴琴琴琴琴琴琴的ミ q第二种呢 是动态的一个创 intentions或者是updated 的成员琴琴琴琴琴琴琴琴琴琴琴琴琴琴琴琴琴琴琴琴琴琴琴的汇現去达到一个细利度的控制弹性的一个行为不同的中文权重啊什么乱七八糟的那这个相对来说是比较复杂的逻辑就是你看K8是原生的一批也非常的简单就是根据指标谈一下然后没有什么细腻度的乱七八糟的东西就是一个简单的谈性生说而如果对这个逻辑来说是比较复杂的对开发者来说对用户来说可能配置起来使用起来都比较复杂然后还有一个缺陷就是我们知道K8原生的一批它就是负责一个谈性生说然后调度到哪些节点是由那个scheduler去决定的那对这种来说这种架构来说它是需要去感知这个集群的每个集群的调度测的类似的它这个职责是比较多的可能和Kamada里面有个scheduler也会职责会混合在一起比较难理解那么这里我就简单的一个优先级产进来做简单的一个实例看这种设计下它会怎么大致的怎么实现我们想要的四啥产量就比较优先级比如说这里Max是30达到24的过后就trigger触发下一个集群的一个扩容那这里就比如说是24或者是80%的预指就是触发下一个集群的一个扩容然后这里就是缩容的场景缩容的场景肯定是比如说这个集群已经扩满了然后这个在开始说达到30%或者是6的时候就触发更高优先级的一个缩容那大致我们想要的最终效果就是这样的那么带入这个第一种设计的话我们看一下效果第一步肯定是触手化下发触手化下发的话我们就是根据API的定义把那个min Max 比如说7或者什么其他的一个策略把它下发到不同的成员集群比如说这里比如说这个Member 1优先级更高Member 2优先级更低的话那么这个min就是1Max就是30然后这个因为我们要限制它的同时扩满有优先级要1先扩所以我这里把它min Max都设成1了限制住那么这种情况下我们去扩容的话可以发生啥场景呢我们可以看一下比如说这个达到30了OK那我要做两步操作第一步要把第一步这个锁住比如说你看我这里min已经改成了30把这个第一个锁住然后第二个把这个改成20比如说我之前那个API里面配置的可能是20那么这几个就给它改成20那这个集群就开始扩了比如说那这样实现的效果就是我第一个集群先扩扩满了 扩不动了然后卡满了把这个API给管理起来比如说我之前说的改min Max把这个改了以后这个集群就开始扩了那它的场景就是这样然后说容其实也是大致同样的道理我们简单开一看一下而就是我这里再说一下就是为什么我这里要把它锁住呢为什么要锁住其实可以比如说我这里扩到20了扩到10了但是现在流量忽然降低了降低了过后那我不可能两个集群同时这样我想的是Mumble二先这样比如说这是公卫云可能花费更高这个是有云不要钱的那我就想这个集群先锁那如果不可能两个锁那我就只能把这个锁住锁得很快就是改min Max你看这是改成30那这个说的话也是同样的道理就是这个达到比如说达到级限值了1了然后这边我就第一步把这个改成1把它锁住这样改成1避免中途扩的时候这个两个集群同时扩然后这个边就是第二步第一步是锁第二步就是把这个min valuemin repellic改成1那这个集群就开始扩了那这样就实现那总体来说这样就实现了一个高优先级先扩然后说的时候低优先级先说那总体的一个策略那这种场景可能就是再来一种公卫云是有云的那种产品下是非常一个通用的场景公私有云混合不属就是公卫云可能花费更多然后私有云因为是固定的资源池OK那其实总体来说就是散来这种去控制这种系列度的控制在不同可能有很多很多种策略那这种控制现在有时候是非常复杂而且用户列起来这个API上面怎么呈现那个呈现可能跟K8原生的API可能几乎差距比较大那用户使用起来可能也成为比较高OK 那我们还探索了第二种一种详细的架构就是也是跟那个差不多第一步从那个API里面定义弹性称为一个指标第二步是这边成员集群我们会安装一个Agent然后它会立刻握起分布式HP的一个Customer Resource然后它根据这个Resource比如说里面的CPU Memory然后去做在成员集群去做计算比如说它是该谈还是该说然后这个计算结果会被update到控制面砍完了这边的一个HPSAR里面去update到一个Status里面去比如说它当前的Missing Pose是多少当前的利用率是多少这种资源 中间结果会把它update到一个Status里面去然后砍完了就会处理这些根据那个散报的指标处理一些异产数据比如说对Missing的数据要做补权然后计算最终的结果然后最终弹性在控制面这边不是一个Busy Deployment它会修改它的实力数然后修改好实力数过后就是比如说Polar它就会砍完了Scheduler就会根据那个策略的一个配置然后那个集群的实施状态然后去调度弹性的一个实力到不同的成员集群比如说优先级比如说权重还有其他的还有比如说动态权重实施的一个状态那这里这种架构来说现在说是非常纯净的就是说CtrlHPA的一个控制器那个API几乎也跟前面的那个单级性的API那个几乎一样的但是它也有缺陷就是有多了个Azint那你就需要维护这个升级和一个版本相后兼容比如说两个版本相后兼容那这个大概成本也是先对来说可能比较高的我们还是以前面的一个作为一个实力看大概是什么样的就是第一个我们创建了一个CR然后这个Azint会list watch这个资源然后它会把那个中间结果这个中间结果不是我们所说的单纯的replica它可能是它更详细就是包含比如说Missing Pulse, Unready Pulse, Ignore Pulse这种更中间的结果的数据会updateCR的一个Statue这边去然后这个HPA controller会根据这个结果比如说处理一些異常数据然后去scale这个workload的一个replica然后这个workload的replica加上调度测量调度测量然后就会调度到不同的一个集群比如说这里就是我们会在membr1集群里面去把replica给加到顶的数据然后加到顶没资源了过后然后我们再在集群二再去把那个实力数调上去那说的话也是同理的就是先说这个再说这个就全部有调度去控制那这个架构来说可能更接近单级群的一些PA就是我HPA controller只负责弹性的实力数然后scheduler决定调度到哪个节点还有比如说节点清和性一样那些八道的OK那我们可以简单看一下design和design二这两种有啥区别第一种是更小的一个维护成本因为它没有Azint的一个组件不需要管什么升级的然后第二个是它更粗略的跨级群谈一声说因为我们刚刚说的它是先单级群谈一声说它没有一个善立视角可能跨级群声说效果可能更粗略还有一个是它的弹性和调度也属于有一点混合的意思就理解起来可能比较困难然后design二的话就是它有一个较高的维护成本因为有Azint或者版本兼容但是它有更高的一个跨级群谈一声说就是成续群报结果然后Kamanda通过善立视角去综合去跨级群谈一声说然后它下面还有一个重点就是调度和弹性是分离的一个职责这个跟单级群谈一比较是几乎一模一样的职责OK然后我们最后就是再来讲一下它们两个的不同的应用场景那这种centralized的适用啥场景呢就是你需要弹性的规模你需要match Biden贷宽的一个大小然后资源的一个分配大小你要合适不能说你想谈二十万你只分一兆贷宽那几乎是不可能的因为metrics拉取都拉不下来然后下面就是它的一个更小的维护成本你迁移成本什么的都比较小而且组建也没有额外的组建就一个metric adapter都是在卡玛拉的组建还有分布式SHP这种就是它支持更大的规模而且是带宽有限的然后控制面支援有限这种情况下它是非常实用的但同时就是说更小的带宽更意味着更低的一个更多的一个费用节省那这就是它们整体的一个区别我们社区这两种SHP是共存的最后会共存只是适用不同的场景那中心化的SHP就是非常的简单你几乎就签一下就行了但分布式SHP使用起来是有成本的但是它支持超大规模也许它是分布式的超大规模OK那最后就是我们的一个官方的一个官方文带和getable还有snack欢迎大家加入然后最后大家有什么问题吗大家可以拍一下照就是刚刚看这边介绍就说除了Federal HPA之外然后如果想支持定时的话需要单独配一个Coron的HPA对就是有没有计划就是把这两个合在一起就像KEDA那样就是可以同一个配置然后既支持像这种CPU然后Memory还支持定时这个可能目前没计划他们职责是分离的就是之前我们内部也尝试过各种HPA的混合但那个使用起来太混乱了最后我们它也是把那个混乱的那个舍弃掉了然后就直接拆了一下那如果说像两个这样同时配置的话是这左边这两个是不同的产净就是比如说通产定时HPA是你弹性比如说早餐有点打卡那你直接弹性deployment但是你如果想同时保留一定弹性的话比如说我最少弹性到50个实力数然后你可能还要打卡可能忽然又多了10个人打卡那可能还要一个实力数那你就可能还要一定的弹性能力就是你可以弹性faderity的HPA所以是不同的一个产净那它的那个如果说是在定时之外然后CPU也超过了比如说定时是10然后CPU也超过了30%本来是15的话就是会以CPU为主是的就这个意思那这两个就是最终就是能够协同使用下来有什么问题吗目前没发现什么问题因为我们现在的场景就是我们其实在单几群是用的那个KEDA做的弹性现在我们也在用那个卡玛达几群然后现在的话就是用单几群弹性的话会越没有一个上帝视角就是可能一个场景就是我们现在我们是分发那个KEDA下去可能两个几群最大部分都是10那几端可能会弹出来20然后但是我们很多业务也在用那个定时的策略理解然后所以说我们如果说用卡玛达的话其实我们定时跟这种常规的吃都要支持对如果说我们也在考虑就迁移到faderity还有这个chrome就是如果说就不知道有什么坑会如果你是依赖KEDA那套就是那套matrix那种customer matrix那套KEDA那套的话迁移过来可能要改点东西就是如果你还是用KEDA那套就是我们其实可能不需要去配置具体不需要用我们可能不会暴露这个配置给用户我们其实就是可能会通过我们平台去隐藏但是我们实际上就是这两个能达到定时跟CPU还没有开启的效果理解对那应该是满足你们需求的好的好谢谢你好问一个问题就是说我的理解就是说fader HP刚刚你们也提到了就是说它这个在那个大集群或者说像我们管了上万个炮的管了几十万盒这种肯定是用不了的因为它这个中心化的可靠性基本上是在生产环境是用不上的这个我们之前也看过然后第二个就是说那个提到的那个关于刚刚那个分布式的算力说白了就是说我有两个或者多个运行面的这个集群作为自己的HPA control是吧对然后我可能上边这个commanda就只是做一个coordinator或者做个协调能不能就是你们有没有考虑过类似于这种方案就是说我的control的运算还是在下面就像单击群的这个包括刚刚有那个同时提到的用刻打或者用其他的这个思路但是为了避免出现那种是吧比方说我那个两个集群那个差异化那个特别大比方说我们在双云的这个场景是吧我某一边AZ可能现在已经有50个另外一边可能只有十几个那在这样的话我们的高可靠可能无法保证比方我单边AZ挂了所以在这个分布式的这个场景下我只解决有限的这个场景也就是说如果你的分布式的这个HPA挂了我的弹性依然可以正常工作就是我的协调能力没有了这个是我考虑过的就是我们这个不是一个agint嘛就是agint如果说它健康检查比如说检查到这个控制片挂了它不是之前会list over前的一个资源吗它会在成员集群可能会把那个HPA给创出来成员集群再去用HPA controller去做单独的一个一定的弹性能力就是说但它没有跨集群的一个能力了我们这个是我们是想可能会归到这个agint里面去你们这个agint是list over前那个控制面的那个HPA吗对那你会在它的那个State里面去记录本集群的哪些信息下面的集群这个就是我们详细分析了一个从那个agp 他记录了啥对不同的指标还是不一样的比如说对于resource matrix就CPU memory它是会记录单线那个总的request还有总的usage还有missing pose一个not pose这些各种数量然后这些数量会记录到那个State里面去那也就是说所有的pod不管是健康的还是不健康的这个只会记录一个数量不会说记录数量包括那个指标是吧对CPU的指标或者是内存的指标是的这些计算最终会用作比如说卡曼达比如说他会统一做集群的一个资源的那个数据的补权比如说有些缺失了我该用应该还包括那个每一个集群自身的那个资源的供给情况是吧是的都有这些信息相当于把这个每个集群包括它的资源的供给还有这个pod的情况等等给到Kamada然后Kamada方面去做协调是的如果说卡曼达挂了他这个A静态就可能会把那个相关的一个比如说HPA资源在成员集群串出来串出来过后那就你自己玩了就是没有跨界对我觉得最差的情况就是回到单集群的调那个HPA的情况是这样的话我觉得可怕性可能会好一点是的OK好谢谢不问题吗大家那如果没有问题的话那我们好谢谢感谢大家