我是来自道克的蒋鲜妍这次主要和来自华为的姜伟同学一起为大家分享一次Kimana的跨集群弹性伸缩的场景与实现OK那么本次分享主要从这几个方面为大家展示一下弹性HPA的一些特点那么主要是多集群的资源词是未来的趋势然后Kimana是如何助力的业务去完成这个多云化然后会讲一下这个单集群的HPA的极限然后在单集群中HPA还有哪些的限制最后我们是如何在多集群多云的场景下去实现一个HPAOK那么我们来看一下为什么说多集群资源词是未来的趋势呢那么我们看一下还是国外Fracture的一个调研那么超过87%的企业受访者他们都会在自己的企业中使用这种多云多集群那么并且在87%里面有大约72%都是来自混合云就是可能来自各个厂商各个不同的集群不同的版本那么随着这个云原生技术的不断成熟那么未来多云肯定是未来的趋势OK那么为什么使用多集群呢那么我们先看一下在单集群中还有哪些限制那么在单集群中一个K8它是有柜诶这个PPT好像我看一下不好意思好像有点问题没关系没关系那我们还是继续那么再来看一下这个单集群中有哪些这种限制那在单集群中我们一个K8里面它是节点的数是不能超过5000个然后破的个数它是有限制的也不能超过10万个然后每个节点每个漏的节点它的容器数它是不能超过110个的那么可能还有一些公司他们有不同的业务不同的这个团队那么在一个单集群里面我们去做这种业务的隔离团队的隔离一般都是通过NMS Base那么如果我们转换了多云的话多集群我们可以用不同的集群去做这种不同的业务隔离不同的部门是用不同的集群那么随着这个可以看到这个单集群是有限制的可能未来肯定是这种多集群都都厂商的这种是未来的趋势那么随着这个这个多集群的这个这个试用它肯定也有些挑战那我们来看一下它一般都是有哪些这种限制有哪些挑战那么随着这个集群越多那么我们每个集群的这种重复的配置可能就越来越多也有一些或者是每个集群有一些拆化的配置那么我们还有一些可能随着不同的这个这个业务啊它可能在不同的集群那么这个不同的集群之间不同的业务它们可能也有一些差异然后我们云厂商它们有自己因为每个云厂商它们有自己独立的特有的这些API的这种管理可能这种集群的管理也有差异然后可能就是这就是多云随着你这个集群数量越多这种随便换了场景可能就越多那么我们怎么来提供一种统一的视角去屏蔽这种不同厂商不同不同的集群的差异呢那下面就是来自华为的姜伟的姜伟同学给大家介绍一下Kmada好 大家下午好我是华为云开源团队那个开源工程师姜伟然后前面讲到的就是根据那个多云的优势那我们是有没有一个平台去把这些统一给管理起来那么Kmada就是做这个事情的能够把你那个之前的单集群的业务平滑迁移到多集群比如说享受比如说我本地IDC公共云我先用本地IDC这种场景能够接生你的成本还有你的融赦在各种场景都能够把你解决OK 那Kmada总统来说它就是一个管理多个集群你能够加把很多集群加入这个控制面然后能够无限扩展你的一个次元池比如说刚刚说的单集群只有比如说一万节点那么你可以接多集群然后可以接十万一百万都可以然后并且它是兼容那个KBUS原生API的你可以像那个使用单集群一样使用这个Kmada然后底层的那个多集群的那个形态都给你屏蔽掉了你只需要像单集群一样使用就行了然后并且是开放中立告别板令然后把华云把阿里云都不用然后开箱挤用丰富的多集群那个调度它仍然比如说你可以基于你的region北京 上海或者是多AZ多集群多供应商它都可以做丰富的一个调度策略然后集中式管理就是我们可以给你集中式管理支持供应室友云还有边云的一个多个集群管理OK 那这里我们就简单来看一下那个Kmada总体的一个架构它其实就主要分两部分一个是我们Kmada的一个控制面然后下面就是你的那个成员集群然后它向善那个Kmada向善是提供那个K8的原生API的之前比如说单集群的API怎么用还是怎么用比如说Kubos掉oply一下然后Kmada它有一个核心组建叫scheduler然后还有一个叫exclusion controller然后你把你的那个APIoply了过后你再定一个多余的一个policy比如说你GPAZ去调度然后它那个scheduler会去根据这个你的策略它把你的不同的workload分配到不同的那个集群比如说是拆分根据可用资源谁哪个集群可用资源多那么就调度到哪个集群比如说北京多那就调北京你仍然还可以更高级的比如说你写一个插件去比价调度比如说比如说阿里云更便宜那你就调阿里云华云更便宜就调阿里云这种更高级别的一个省成本这样本征效的一个调度你仍然可以这么做OK那现在有一个核心问题是你之前是单集群通常都用那个HPA去保证那个服务的稳定性就是你油量多了那我就弹性这个破的数那么在多集群的场景下就会涉及弹性的一个伸缩需求那总的来说就是如那个左图一样就是我想突破集群的边界比如说集群一油破的数 流量来了然后我就想跨集群弹比如说Cluster1和Cluster2都弹那这个总的来说就是我想统筹打破这个边界统筹多个集群的资源实现跨集群的一个弹性声说就比如说我有本地IDC通常的不数价格我有本地IDC价格公共云然后本地IDC资源弹满了过后我再弹公共云这种场景就是说我本地还撑不住然后我再用公共云去cover这个流量或者业务这样就能够省很多的成本好 那总的来说需求就是这个OK那我们来简单来讲一下那个HPA的局限我们那个蒋兴健同学好 谢谢那我们再来看一下在单集群里面这种单集群的HPA还有哪些局限性我们先简单的介绍一下HPA它的背景它的一些使用方式那么我们这张图是来自K8官网的一张图我们先简单介绍一下HPA它的整个工作的原理那么HPA它就是根据它会在每一个时间周期内根据你的设置会在每一个时间周期内HPA的控制器它会根据你在HPA的压秒文件中的定义去扫描你的那个target的目标比如你的一个deportment它派生出的POD它会根据那个deportment里面的那个spec and selector去选择那些POD然后根据POD的那些指标去查询这些POD里面有哪些比如你是标准的那种资源的话比如POD CPU或者是内存如果你也可以制定一些制定的指标比如像什么HP别请求总之你可以做一些自己业务上的一些配置那么HPA就可以根据你的业务比如你的业务流量突然上来了HPA就可以帮你把这些POD去扩展去扩缩容对然后如果你的业务流量过去了那么HPA也可以帮你把这些POD最缩回去主要去节约成本对这是简单的一个单级性的HPA的介绍然后我们来看一下它是怎么使用的这是也是来自一个K8官网的一个样率这里面这个HPA整个业务配置可以是非常清晰的它有定义了一个target的就是你这次本次扩缩容你需要去扩展去扩展哪些deportment比如像这里是一个PHP的aparch的一个deportment那么它扩容的这个指标就是根据CPU按照CPU50%来扩容意思就是我们可以要维持整个这个deportment它的CPU平均CPU在50%左右那么我们现在知道最大最小副本数就是它会根据你的比如你现在可能有5个但是你的业务来了你的CPU突然猛增到了70% 80%那么它就会帮你扩缩容可能到89个到10个以维持这个PortmentCPU到我们设定的目标可能你的业务流量过去了之后那么你的Portment可能就CPU因为刚刚扩缩容了扩的可能比较多那么你要解决成本你需要把这些Portment它就会帮你把这Portment缩减回来那么这个真说的频率你也是可以通过这个可能这个压枚没有定义里面有个behavior之段去控制你的扩缩容的这个步骤这个节调你可以快速扩快速扩容慢的很慢的缩容等等都是可以根据你的需求来的这是在单级中HP的势力OK 那我们来看一下在单级中它它这个定义很清晰它肯定有一些局限性那比如我们这里有一个典型的场景你的一个集群中你的资源可能不可能是无限多的我刚刚在前一张PBT你也说了单级它有资源资源的限制不超过多少多少POD的数不超过多少那么一个单级群里面它的资源是有限制的当你的业务流量来了之后你不可能无限的在这个集群中扩缩容那么此时你可能就希望将你的这些业务的POD转移到另外的集群里面去那么假如你还有一些一些场景比如你的POD扩缩容了但是它更失望一些比如高成本的这种云场商里面去扩缩就POD本来你肯定是想让一些云场商的这种比如这种价格是不一样的可能你更希望它这些扩容的POD去到那种低成本的云场商去但是在HPA里面它是没有做到这种可以根据成本去调度的又或者说是我们现在每个集群都有一个HPA那么随着这个集群的越多这个数量越多HPA这个配置就越多那么可能我们有更希望有一种统一的方式去配置每个集群的HPA来统一的去管理维护这个HPA的限制这些资源那么这个单级群中是很难做到的下面的话来介绍一下在Kmata中刚刚姜伟同学也介绍了Kmata是去管理这个多个集群多个成员集群提供一种统一的视角去帮你去部署这些资源那么在Kmata中我们引入了一种Futurity的HPA这种一种集中式的HPA这个HPA它的特点就是非常简单一用与我们单级群可以把它保持一致但它的特点比较鲜明就是它可以帮你把这些增加扩手容的POD去更好的调度到每个集群里面去根据你的这种分发策略你的分发策略是想让这些POD到低层面的场上去它就可以满足这种需求然后我们整体来看一下这个HPA的Futurity HP的定义我们可以看到它整个的定义与K8IS里面的HPA的定义是几乎保持一致的我们可以看到它有Target的指向给哪个资源扩容或者是你的想根据什么指标Matrix的指标或者是你的behavior你想扩售中的步骤是想快速的扩容还是想慢速的扩容整体的这个API的定义基本上是和单级型的是一致的那么这就意味着如果你已经使用了HPA的话那么你就可以很简单的从一个单级型的HPA转移到我们迁移到我们这个多级型的HPA里面Futurity HP就是多级型的HPA可以看一下它基本上是除了我们的API Version和CANDA是不一样之外其他的之外都是一模一样的对你来说可能就是将要么要简单的做一点点修改这些小的成本的迁移然后下面核心的这些指标比如你是想对哪一个Department的做这种扩容根据什么指标这些你都可以不需要更改因为你可能有大量的HPA我们都是尽量的去兼容的那么你只你迁移到的你可以写一个小脚本简单的小脚本就可以批论的把你的HPA从单级型迁移到多级型我理解应该是对用户比较友好的然后我们来看一下它的使用我们从这个定义中就可以看出我们的定义是为了去与单级型中的HPA保持一致所以我们整个使用的方式也是和单级型中的HPA是一致的那么在单级型中我们需要使用HPA的话我们是需要创建一个Department这些就是你的业务然后你需要一个HPA然后在Kmata里面是叫做Fooderated HPA由HPA去管指向你的这个Department然后因为在Kmata里面它需要将你的Department分发到不同的这个分发过程中可能你需要一些这个调度策略比如你可能需要哪个集群多哪个集群少按照权重或者是按照这个资源的利用率比如说底层的资源利用率高的你就少一点资源集群底层的这个比如说Member3它可能它的资源很丰富里面跑业务的这个Port很少你更希望将你的Department调度到Member3里面去那么我们HPA在扩缩容的时候HPA在扩缩容的时候它通过底层我们Kmata里面底层有个叫做Fooderated HPA Controller这个Controller它会去Watch它会去一直周期性地去查询Mesh Adopter这个这个组件这个组件它会搜集成员集群的你自己成员集群的Mesh Server的指标将它聚合起来然后在Kmata的控制面来扩容Department然后在Kmata里面如果你在控制面扩容Department副本数比如你将它从两个扩到十个的话那么这个扩容的这个数量会受刚刚姜伟同学在上一张批评说它的调度器来控制然后调度器是根据你的分发策略按照你的预期将扩容的数分到不同的集群那么此时可能你的底层真实的成员集群有个集群它的流量很高导致它的整个利用率很高那么调度器在调度过程中它会感到整个底层集群的这种资源的使用率它就可能把你这个扩容的这些数量转移到其他比如像Member 1Member 3这里面去整个过程中就是尽量维持我们扩的能避免往一个集群里面打或者是让你的流量或者你的业务更加稳定OK这是整个工作流程可以看它整个工作流程其实和单集群的HP的工作方式是一模一样的你的使用方式也是一模一样的所以只是有一个理点区别就是在Kemana中任何职员的下发都是需要一个分发策略来分发你的Department是如何到这个集群的然后我们简单的介绍一下它整个的价格刚刚也说了在Kemana中我们是引入了一个Kemana Matrix Adopter这样一个适配器这个适配器它会周期性的它会去查询就是你的Controller周期性的想去查询指标的时候它会请求到Kemana API ServerKemana API Server你可以理解为它是个原生的API Server就是跟你单集群的API Server是一样的对 我们基本上就是用的就是单集群的API Server所以Kemana API Server它就会去查询这种比如说单集群里面它就会去查询MAC Server那么在Kemana里面API Server它就去这样请求转发到现在的Kemana Max Adopter这个里面去然后请求来了之后这个请求就会真正真正地去底层去搜集你这个HPA里面定义的那些指标那些Deportment相关的指标那么这个我们要使用HP比如这样单集群你要使用HPA的话你需要装一些MAC Server或者是一些自定义的MAC Server有你可能要根据你的HDP请求做一些业务的统治那么你也需要再集群装那么所以这些组件可能在你的集群你是天然就具备的那么整个Kemana它就可以把这个指标从各个集群搜集上来聚合到整个控制面对它的大致的流程就是这样子的可以看到它的整个工作流都是和单集群的HPA是保持一致的比起我们的Federality Controller它的整个工作的机制也是和单集群的HPA Controller是一样的对当然它也有一些不同因为我们在Kemana中它的策略就是你的分发策略有一些不同有各种各样的策略可能你还有一些自己的调度策略调度插件所以Controller它也有一些些的行为与单集群的Controller有一点点不同对但大致的体验是基本上与单集群是一样的好我们就来看一下我们集中式的HPA它的适用场景那么刚刚也说了我们整个Federality的HPA它是与单集群的HPA保持一致的所以对用户来说它的迁移成本就比较小你只需要改APS Server和CAN的对 这些都是固定值对然后我们在扩兽容的时候就是在Department的副本数在控制面移扩容的时候那么扩容得多的这些实力数它是受Kemana调度器来调度的Kemana调度器它是可以赶到成员底层的资源的情况有哪些资源剩余多哪些资源剩余少它这个多的副本它就会按照你的想法可能就是预期的想望资源余集群多的资源去扩兽容那它也有一些稍微有一些局限就是可以让它整个工作理由都是位于位于这个Kemana控制面的所以它对这种Kemana控制面的这个压力是比较大的对然后因为我们刚才从这张图片可以看到整个Metrex的指标都是从真正的是从底层的Metrex搜集上来的所以这种Kemana它需要去比较对你的这个成员进行到Kemana中间这个链路可能要求比较高因为像Metrex的话它可能变化是比较平凡的对所以它可能需要你在控制面和成员之间的这个带宽可能需要比较多OK 这就是整个Kemana集中式的HPA的一种使用场景那么在Kemana中其实还有另外一种HPA就叫分布式HPA那下面有请江伟同学来跟大家介绍一下分布式HPA好 感谢欣彦同学的讲解然后刚刚我们看了就是那个中心式的HPA它的核心优势就是焦度精度高还有原生体验你的签议成本非常非常的小就改个HPA和Version那如果可能你的业务规模更大带宽可能更低那这种情况下我们你就可能得使用一个分布式的HPA了在Kemana这边叫HPA Coordinated它其实就支持就是分布式的它那个计算相关的都不在控制面那么它就支持更大的业务规模更低的带宽要求和更低的控制面负载它的核心优势就是这些然后可以看一下整体的价格就是还是在Kemana控制面我们有一个叫HPA Coordinated Control的一个组件然后线扇是提供一个叫HPA Coordinated的一个API这个API会定义每个集群的那个HPA的API展什么样然后它会做下发那个HPA Controller下发到每个成员集群的HPA由HPA Controller单独再去做计算弹性伸缩然后HPA Coordinated做到啥来在这个里面就是比如说为了实现优先级扩缩它可能就只做了就是把一些把一些低优先级的集群比如说给disable掉然后高优先级群如果资源用完了没得用了那么我再把它enable掉也许它就是做了这个事情可以看到它整个的链路就不需要Metrix从控制面和成员集群来回交互了就不需要了然后Metrix的采集和计算缓存都在成员集群那么这种情况下就负载会非常低或者说几乎没有消耗资源消耗然后我们整体来看一下就是它的核心的区别第一点就是控制面的负载中心化的中心化的话它是相对较高的因为刚刚说的那些Metrix的采集 计算缓存都是在控制面它的负载相对较高而LTP coordinator负载会相对较低因为刚刚说的那些Metrix 采集 计算都是在成员集群自己做控制面不管它只是做一个协调那么负载就会相对较低然后带一块要求也刚刚说的就是Federation会控制面和成员集群会存在数据交换我们之前测过就是百万铺的一下交互一下可能要好几百兆而变化周期是会很频繁的所以对你的贷宽比如说你的贷宽是按流量收费的可能你查一次就好多好多钱那这个可能对那些加本增效的企业可能就比较明显然后Cordinator因为他没有数据交互Metrix交互所以他贷宽要求几乎可以不小然后下面一个就是跨集群的精度就是Federation他的弹性就是扩容的那个实力他是能实时感知到那个成员集群的状态可以给你调到比如说低负载的集群所以说他的那个精度说相对较高而Cordinator是把那个全线下发了类似他那个精度就相对较粗略而他没法感知每个集群的一个资源状态他只是做一个HP的启停的一个操作所以说他的精度相对较低就跟类似我把全线下发给每个组每个组自己做还是说我自己做我自己做就会很累但是他的精度就会很高而我下发过后我可能就全线比较少整个团队的进度可能比较弱但是他我就比较轻松了类似OK分布SHP总体的一个传讯是展啥样呢我们可以简单看看两个图就是一个是生一个是缩OK右边那个图就是它是你们应该是左边左边那个图就是扩容的产品就比如说我设置一个集群的MIMAX然后他跨集群那个扩容的预值是24也可以设置百分之八十然后达到24了过后然后就开启第二个集群的那个扩容就说我达到某个预值了我接下来的跨集群扩容做准备那就把第二个集群的HP给开起来它慢慢再弹上去那缩容也是同理就是说我在缩的时候达到某个预值比如说6或者是百分之三十然后我就把那个更高优先级的集群那个HP的缩容给打开OK那大致的流程场景就是这样OK那我们接下来就整体看一下它那个分布成HP那个大致的流程其实就三步初始下发缩容和扩容这三个场景其实这三个场景搞好了搞懂了其实就比较好理解OK那假如说我们还是以劣质的那个形式讲解假如说我们那个Member一集群高云Member二这种场景是很惨见的就比如说你有公有云和私有云那你的资源肯定是先用私有云因为为了省钱所以假如这里就Member一高云Member二然后Member一集群的那个Memex分别是E30Member二分别是E20为什么要我们要这么设计呢是因为这个API对诱惑来说可能比较突兀但是这个API基本上是给那个管理员用的管理员用的时候它是想细利度控制每个集群的资源资源可资源的那个状态的它不想忽然谈谈了很多很多然后导致的这个集群断浮了细利度控制所以我们这么设计的然后下面就是那个跨集群的那个扩容触发预指我们这里是30假说Member二的硕文预指是1为啥这么为了后面好演示好理解我们这里就不设什么24刚刚那个图的为了好演示好理解OK那这个我们这个配置好了那么它下发的那个API是什么样的呢可以看一下那个Member一它的Meme Max就是E30实力数初始实力数1然后Member二就是111为啥这么设计就是因为Member二集群的那个API给关掉了关的方法就是Meme Max一样它就它就谈不动了初始下发过后然后它肯定流量来了假如说我举个例子这里就是Member一流量上来了它那个current replica就变成30了然后这个时候就要触发那个集群二的一个扩容了嘛那扩容怎么触发扩容就是把那个Max replica直接改成20改成20过后呢然后这个Member二集群它就会慢慢流量涨过来然后那个实力涨上去嘛所以那就实现了跨集群扩容那跨集群扩容过后那我们首先还要想一个不能说比如说我谈集群二谈到了10个忽然又降了这个流量降的时候我们是先要保证集群二这降集群一先补降那这个补降怎么实现就是把那个Member replica也改成30给它锁住了一些就是Member二一集群那个HPC给它锁住就不要你降了OK 那这么这个流程可以看一下就能实现我们说的优先级扩容那我们再讲一下缩容这个流程大概是怎么样的假如说还是两个集群然后刚刚我们那个不是扩到30了吗OK 那现在Member二集群在说也就是说到一了那说到一了过后我按理说就要说Member一了然后说的怎么跨集群说的呢还是跟那个之前的原理是一样的就是把Member一那个Member replica改成一然后就开始说然后同时要把那个Member二集群那个Max replica改成一因为到时候说到中间又扩为了避免集群二先扩所以就把那个锁住了一些就是关掉你可以理解成那么这种情况下就可以实现Member一说到几线了说不动了然后再说Member一你可以理解成公勇云先说说完了然后再说是有运集群那么你就能省很多很多的成本那大致的流程就是这样OK那其实还有一个问题就是我前面说的那个那个预指就是刚刚说的一个24或者是84有什么用呢这个我们可以还是举个例子来来用就是假如说我有两个集群本地IDC还有一个公勇云然后我扩的时候肯定是想公勇云先扩哦不那个叫色云先扩然后再扩公勇云那这种情况下就是假如说这里达到124然后根据Max replica它那个replica会持续增展一直在展然后展到30的时候我们就出扩容触发预指了触发扩容预指了然后去公勇云上去扩容但是这个时候你知道公勇云我们为了审承本一般是你是装了那个class-throat-skiller的去动态去创建那个暗虚的节点那这种情况下你这里到达30再去触发那个节点创出来一般要5分钟或者是更惨一般是3到5分钟那这种情况下这3到5分钟内你的多个集群这个业务都是过载的可能会断幅那所以说我其实想要的不是达到30的时候去再触发公勇云可能达到80的容量那我就想去触发公勇云把那个节点给扩出来然后后来再扩容出来总的来说就是如果你达到30的时候再去扩容那可能会长时间过载导致断幅那现在我们来看一下之前是设置前那现在我们设置后会变成啥样的我们看一下假如说我设置了80%容量达到80%容量我就去触发公勇云扩容那公勇云扩容就是那个Cloud然后触发公勇云扩容过后它会触发那个节点节点扩容节点扩容会持续扩容你看两边都是持续持续扩容的节点扩容成功过后然后那个本DIDC这个本DIDC它达到那个Max了过后其实这里的节点已经扩出来了已经扩出来了那么这种情况下你就算业务再来那个流量再红红再过来其实也能Handle也能Handle但是如果说你的那个业务流量和风太大了太大了可能太快了那可能也要等一段时间去才能Handle但是如果你的比如说正常情况可能不是这么小可能是一千两千个两千个破的那这种情况我的意思一般是能够Handle这种因为你时间不会刷一下一下就转下去的所以我的意思能够Handle这个场景的OK那么总的来说我们可以看一下之前设置前如果是那个预指设置的比较合理它一般就是解决你的公共云和私有云这种场景避免长时间过载这个问题的OK那最后我们总结一下他们两种的适用范围到底是什么样的就是第一个如果说你的资源有限制就是从两方面资源限制和你的扩松策略扩松策略如果说你的贷宽有限或者说你的贷宽比较故意或者什么的那你用规模比较大的话那你可能就不得不选择去中心化的SPA然后如果你的贷宽足够而且那你就可以使用集中式或者分布式集中式的优势大家说就是学习成本极低你可以直接复制过来分布式可能就稍微复杂一点但是它带来的好处也是巨大的然后第二个是负本数扩松的一个局限性就刚刚我们演示的就是如果你想按优限级扩松目前你只能可能用去中心化的如果你想后面可能会扩展看完的那如果你想要使用Projecting Policy里面的各种策略比如说可用资源数那种去跨集群扩松的话那你目前可能只能选择集中式的SPA那主要所以你想选就取决你的那个环境呢那最后的话就是我们大家如果有兴趣可以关注一下我们的卡玛拉光碗还有Equitable Snack还有社区小助手什么相关的对感谢两位老师的精彩分享大家有什么问题可以举手提问那个我想问一下就刚才讲到就是那个应该是这个去中心化的这个但是说的一个场景就是说它是有那个本地本地的集群和那个云上的集群然后它那个可以设置优先级就是它那个优先式弹优先式先把本地的打满然后再往那个云上那个调度对对对然后但是它缩容的时候我看您是说修改一下把我那个本地集群的那个就是最小的复本书也给它调大对对然后这样才能保证它不会把本地的那个先缩掉是的就是这个手动操作是不是有点能不能自动化的比如说我这个都是自动化的这个都是我们那个卡玛拉它给你全部自动化了就是我缩容的时候它自动会把那个对对就是那个Mine replica对对对控制面给你自动全程自动化了对对明白就像我配置的像本地集群的这个它的这个优先级之后它就自动化了对对对好好了解了解那没有问题您好我想问一下那个这个缩缩容的时候是缩容可以指定远击缩容也可以指定远击不一不一样是吗目前是只能是比如说优先级你指定一个它是缩是顺着来说是反着来也就是先扩后创建的先背衫对对对那是合理的对然后第二个是我看了一下这个是每个集群的APA的一个策略我应该我需要去创建的应该是整体的一个吧对整体的我需要创建一个整体的比如说控制面控制面创建然后整体比如说最小是一最大是三十然后设置一下两个集群的比率比如说7比3你自己会根据我设置的比率以及优先级两个业务集群根据我的比率去成为一个百分比然后决定它最小的最大不是这个还不是这样的我们是想因为为啥不这样做因为管理员平台管理员如果你啊就算比例去分它分到下面也有点不可预期你可以练成我们想管理员你有能力去全权比较细腻度的设置每个集群的MIMAX你这样会控制每个集群的MIMAX远转抬要不然可能会超可能会少所以我们想的是比较细腻度的一个设置每个集群你分别设置一下在控制面比如说一个list一个arrow然后里面分别设置一下每个集群的MIMAX我需要自己手动设置对可能后面会有眼睛但目前是这样这个扩作容一次应是一个事物这个做完之后我如果它正在扩作容的过程中我做了扩作容配置的修改它肯定是等这一次做完之后才会做扩作对好的我们有其他问题谢谢老师大家还有什么问题吗我爱问一下有龙栽吗有啊都有就是一个两个运集群有一个挂掉了对龙栽是怎么做的龙栽就是目前假的说我举个列就是共云和北京和上海假的说那北京的集群挂了我们会做健康检查所以集群有个Helsey还是ReadyZ还有我们支持比较有plugging的这种健康检查集群你可以从共云的接口去捞那种健康数据也可以然后检查到挂了过后我们就会把你的那些业务全部重新部署到其他集群去你可以设一个backup的集群你可以设对谢谢也可以选的集群大家还有什么问题你好 我想问一下就是目前听您分享的它都是基于一些集群中泡的数量或者是一些CPU占用的之类的出发条件它现在支持那种手动提前扩容的场景吗手动我们现在社区在研发一个叫Chrome Federich DGP就是你可以提前比如说30分钟提前扩容也是可以的比如说比如说每年31每年618什么都可以明白谢谢感谢那个那个还有个铜线感觉我是一个你好 我想请问一下因为我知道很多室友比如什么KS 包括DalkerDalker的还有那个博文产用他们其实内部采用的多集群都是采用的困难还有就是你们这个苦帮跟那个Creative他们有什么区别呢对那个无头肤的Creative就是Ceralise就也是安妮的那个你是说和苦薄薇娜的区别吗对对因为你们这个涉及到一个HPA包括那个很多模式其实跟那个Ceralise的Creative他们是很多底层都像像的比如说一个流量打过来它会拉取很多一个泡的对对 流量大了它就拉去泡的然后流量小了就会自动减泡的然后包括就是像那种Membrose集群他们是有一个Cantuna集群做一个集中管理嘛对不对是的对对对然后像那个下发过来之后业务量它的流量打过来之后其实你们底层跟那个Creative之间有什么区别呢因为我觉得很像跟Creative是吧对对对就是Race的Creative我的理解因为Creative也是长在K8上面就是把Ceralise的业务封装成K8的POD对对对我的理解Kate可以绕在上面可以借助Kamana绕多集群把这个Service业务绕在多个集群的那个还有一个就是比如说像青云的KS他们其实采用了你们这个Kamana之后他们是内部插件有个CCM这么一个插件对因为它是一个类似于联邦模式嘛因为你们Kamana应该也有类似于联邦模式这么一个模式有吗好像可能是他们自己封装的一个模式就是青云的KS他们自己封装的这么一个模式OK像那个因为我不知道你们这个有没有测试过那个就是多集群那管的一个建状性就肯定有一个建状性的那么一个插件对吧就像我要一个多集群之间的一个年级中间肯定有个插件或者有个Kamana那么一个组件来实现那个联通性对吧你说的多集群你是网络的联通性吗不是就是集群之间的那么一个联通性比如说我要通过Master组集群对我的那个其他分布式集群的这么一个Member集群的这么一个管理对对对对肯定中间他们是需要通过有个插件来作为一个支撑或者联系的有一个Ctrl去做这个东西对对对有对这个Ctrl做过测试就性能的压涉我们是测过的这个Kamana那个官网是有那个相关的测试的对因为相对来说我觉得这个组件它应该是最重要的一个组件之一吧应该这个组件应该算是最重要的一个组件之一对对对OK好的那个你可以如果对性能那个稳定性有那个想看的话可以去官网我记得好像是十万个集群对因为在官网是有详细的压测的OK因为清云他们还是说可能Kamana的问题因为他们是集成了你们这个东西在他们那个产品里面对因为在我们那出过很多问题了对所以我才问这个问题Kubo Vela没有集成Kamana它集成是OCMOKKubo Vela是用的OCM多多集群管理跟Kamana是没关系的我说清云的KS好像是集成了清云集成了你们的之前是集成了是Kubo费的对对对它现在的版本是集成就是你们Kamana清版本是吧对对对清版本所以我才问这个性能的问题OK然后这个性能的问题之前我们也做了压测就是用了很多工具就像刚才上午有一个同学分享的那个keywork我们也用了keywork去模拟了非常多的集群去把它接吻到Kamana里面去纳管这么多大批量的集群去看看这个Controller整体的这个性能对大家对这个Kamana SBA的这个兴趣非常高涨建议一下还是因为时间关系吗建议还是先下去麻烦我想问一下具体一点它这个应用场景在哪些这个行业比如说你们这个应用这块比如说公有员私有员的这块做一些举例举例具体场景一定要落地一点场景落地的场景其实比较典型的就一个同城多活类似于同城多活准备融灾就比如说你北京上海不一下北京上海不一个集群业务不属的这两个集群然后有个集群挂了那我给你自动迁移就刚刚问的自动迁移而不需要你手动写什么Alert然后再手动去重新re-apply一下那就不用了这是第一个场景第二个场景就是你刚刚说的我有本DID是和公有员那我部署业务的时候有亲和性的循环我先调本DIDC因为更便宜或者说不花钱那公有员更贵吗那这是两个非常典型的场景应该就好其实调哪些改为这个我感觉可以现在进行那个沟通因为时间限制谢谢两位讲师