大家好,我是来自火山引擎的沈铁晨然后目前主要是在研究多云多级群的方向然后今天很荣幸和来自Vivo的张荣老师一起分享一个议题是如何在一个多级群联邦中飞青入世的使用一些像OpenCruise和AgoFlow这样的第三方的工作负载项目来帮助用户更好的从单级群的架构嵌移到多级群联邦的架构然后本次议题主要包括四个议程首先我会来介绍一下多级群联邦的一个背景其次我会简单介绍一下从单级群嵌移到多级群联邦的一些挑战包括一些集成一些第三方的工作负载项目然后这里会以OpenCruise和AgoFlow为例然后对给不熟悉这两个项目的一些用户做个简单介绍OpenCruise是一个扩展的应用自动化的一个编排引擎AgoFlow是一个主要用于离线任务的一个工作流的引擎然后其次我会以Kamada这个多云编排项目为例介绍一下它的这个资源解决器的一个框架这样的一个解决方案然后最后会由张文老师一个end user的一个视角来讲述一下在Vivo内部他如何从多级群迁移到集群联邦的这样的一个实践OK 首先我们介绍一下集群联邦这样的一个背景其实我们为什么要提到多云多级群这样的一个技术这里提供了一个表格是在23年就是一个著名的一个调查机构对一个企业的一个用云的一个姿势的一个统计然后这里我们可以看到其实87%的一个企业用户已经在用到这个多云的一个架构然后其中72%是混合云的这样的一个形式其实我们也可以发现多云这样的一个用云姿势其实已经越来越被更多的一些企业和组织所接受那么多云多级群可以典型的分为三个典型的一个阶段然后阶段一的话就是孤立的集群这样的一个形式其实这种情况下我们用户往往有多个集群然后我们会用单独的一个凭证去管理这些集群当然在这种这个阶段里面其实我们用户无法做到多级群统一的一个应用下发以及应用的一个访问其次每个集群其实是一个资源的孤岛我们也不能合理地把多级群联邦的一个多级群的一个资源给用到集制然后第二个阶段是集群组的这样一个状态在这种状态里面其实我们可以做到多个集群的一个统一的应用的分发应用的访问和统一的一个调度然后第三个阶段是统一的一个资源池的一个形式这也是我们最终所希望的一个形式就是把多个集群作为一个统一的一个资源池然后用户不需要关心这个集群的位置在哪里然后集群的属性是什么然后它可以自由地使用这个实力以及对应的流量然后我们现在其实处于阶段一再往阶段二的一个发展过程中那么管理多个K8S集群其实会有非常多的挑战那边我简单列举了一个非常典型的一个四个挑战然后第一个就是集群数量很多过多导致的一个重复配置的一个问题然后第二个挑战是工作负载的碎片化然后不同集群间的应用它其实无法做到一个同步然后服务其实也不能互通然后第三个问题是受集群的一个边界的影响其实K8S的Cluster的这个逻辑对象其实把资源天然的给隔离开来了也就是说一些常用的一些高级特性它其实天然受集群的边界所影响比如说应用的一些高可用部署然后包括HPA这些都是受单级群的一个边界的影响然后最后一个问题就是厂商绑定的一个问题就是用户我们往往都不希望能够只绑定在一个单一的一个厂商这样的话其实我们就无法选择到一个云厂商一个最好的一个服务然后那么我们也回顾一下社区对多云多集群做出一些努力其实社区很早就注意到这个多云多集群这样一个趋势然后在2015年的时候已经我们已经K8S社区已经成立了Federation Seag然后到2018年我们上游社区其实先后开发了Federation V1和Federation VR然后但是QVF的也就是VR其实后面也面临到一些问题然后到今年就正式被废弃然后一些中立的一些多云群项目开始逐渐走向成熟然后整个社区的生态也变得一种百花齐放起来包括Kamada,Coopier,Maro, OCM等等那么介绍完了背景之后我们来介绍一下千仪和集成的一些挑战那么我们首先回顾一下QVFED的这个架构其实QVFED相比较V1其实也带来了一些很多的优势包括它采用了一个模块化的设计然后它把一些多集群的一些调度包括差异化的一些API给结构化了这样的话可以把它从单级群的这样的一个资源对象里面解有开来但是它还是没有解决一些问题比如说它对非原生API还是没有兼容得很好特别是对一些CRD的一些困难能力因为像原生的资源比如说Department它其实有一比一的一个内置的一个联邦资源对象但是对于第三方的一个比如用户的CRD包括第三方项目的一些资源对象它其实还是需要一些用户的外学习和开发成本第二点是它缺少一个一战到底的一个解决方案就是在QVFED的一些早期的一些用户里面其实非常多的用户对QVFED有一些大量的一些模改就是导致整个社区其实没有走向一个统一的方向这也是QVFED社区最后失败的一个主要的原因那么其实我们也关注到用户其实从单级群它考虑是不是要侵犯到多级群它其实核心其实有两点顾虑第一点就是我迁移的时候我们希望能够在迁移的过程中带马的一些轻入式的改动的成本改动进可能的低这样的话迁移的成本会比较低第二点是它希望联邦使用姿势和单级群使用一些KBIT生态项目是完全一致的因为其实我们非常多的一些用户其实在单级群里面已经用了非常多的一些包括CNCF生态的项目以及它自定义开发的一些operator等等对 但是其实QVFED其实没有很好的解决这个问题然后接下来我会举几个非常典型的一个case然后来给大家分享一下第一个非常典型的一个使用联邦的一个姿势其实就是假设我们有非常多的一个集群然后每个集群其实我们已经部署了一些服务于本地化的一些应用然后这些工作负载可能包括了一些一些deployment包括一些扩展的比如OpenCruise的一些crown-set包括我们自定义开发的有operator控制的一些一些CR一些业务逻辑那么其实我们把它揭露到我们这时候希望我们能揭露到整个集群联邦中并且使用集群联邦的那种高级的统一的一些多集群的调整策略来统一的去分配这些不同的跨集群的去分配处于不同集群里面的一些副本那么做到这个前提就要求我们集群联邦它能够认识到这些未知资源的一个实力数包括这些实力所需要的资源才能够应用我们的一些处于联邦测的一些高级的一些调整策略然后第二个典型的一个场景是我们其实介入了一个联邦然后并且我们现在要去统一的分发我们的工作负载到不同的集群里面去那么其实非常多的一些工作负载包括一些常用我这一举的一个croncius的为例子它有非常多的依赖包括一些secret config map这种配置信息或者是一些我第三方的一些自定义的dependency那么其实我们希望的话在把这些workload和这些依赖能够分发到同一个集群里面去这样的话这个workload才能够正常地运行起来其次对于我们的联邦测来说我们希望能够给用户提供一个统一的一个仕途就是把不同集群的workload的状态能够聚合起来这样我们用户可以在联邦测看到每个集群的他们的一个实时的一个工作负载的状态那么对于完成这一点其实也就要求我们联邦能够能够感知到一些不同的资源特别是一些未知的一个资源的它的一个依赖以及它所用户希望它聚合状态的一个方式然后这一点其实Cruify的也并没有做好然后第三个第三case其实是我们对于一些workload来说其实我们在从联邦分发到成员集群里面去说将会遇到一个情况就是我们联邦的控制器和成员集群的控制器它会去同时更新某一些资源的一些自断那有导致它会形成一个冲突的现象那么最终就会形成一个死锁导致我单集群用得好好的但是我放到联邦里面它就并没有用得很好比如说argo workflow就是一个很好的例子它是一个非常典型的一个工作流的一个负载就是会由多个的一个step来构成然后每个step我们可以认为是一个非常小的一个job然后它执行第二个step的前提是第一个step的那个状态已经是complete的这样的形式但是在这种情况下的话我们联邦其实并不知道状态的一个修改是成员集群的正常的一个更新还是说我们用户的一个一些物出发包括一些其他的形式那么联邦会为了维持它的联邦跟成员集群的一个统一它会做一个override覆盖这样的一个行为这样导致我们的单集群的业务会无法正常地运行起来包括同样的例子也有HPAA也是这样的例子那么其实对于这种情况下其实我们希望当冲突发生的时候我们希望能够让用户去决策这个冲突到应该怎么去解决然后我们应该是听从联邦的一些调度决策还是说听从成员集群控制器的一个决策然后接下来这些问题其实都需要我们在把一些单集群签到多集群里面会需要我们对各种各样的一些资源对象能够去做解析包括这些资源对象有不同的处理方式那么如何灵活地去处理这些问题那么其实就需要一个通用的一个资源解析期框架然后卡玛拉其实是一个非常典型的一个多运多集群的项目然后它又实现了一个通用的一个资源解析期框架来帮助用户去解析资源的一个结构那么其实对于场景一卡玛拉提供了一些interpreted replica和revised replica这样两个解析器的这些操作能够对一些能够解析到一个资源的一个实力包括他们对你所需的资源然后对于对于我们刚刚说的场景二它提供了一个interpreted dependency和aggregated status来帮助用户去给得到这些特定的一些资源对象的一个依赖以及他们聚合状态的一个方式那么对于场景三其实我们提供了一个return的一个方法让用户去决策如何去处理冲突在联邦和成员集群的控制器中然后此外还提供了一个interpreted health这样的一个解析操作其实主要是用于联邦去识别到一个应用的它在一个某个集群的一个健康状态这样的话基于这个特性我们可以做一些跨集群的一个应用故障迁移等等一些高级的能力然后其实解析框架其实实现了一些内置的和一些自定义的一些解析器然后内置解析器其实我们主要是针对一些k8s原生的一些资源包括一些知名的一些第三方的扩展资源那么自定义的解析器会去实现一些比如说用户自己的一些业务逻辑以及一些特定的就是跟我们一些自己使用资设的 符合自己使用资设的一种实现方式那么比较常见的两种实现一种是我们通过外置一个webhook的一种形式那么我们其实也是类似于常规的那种一个hook这样的一个机制比如说在应用一个调度策略的时候可以在对应的hook点去执行对应的一个解析器操作那么第二点其实这个方式其实也会提供一些额外的一些开发成本那么现在我们提供了一种更灵活的一个解析器方式它其实是基于声明式API的那种方式用户它可以去自定义这个自动解析器既可以对kbis的资源可以对自定义的一个CR的一个资源然后这个解析器的一个API的声明其实是基于那个Lua脚本的一个非常简单易懂的一个函数式的一个实现这个可以实现一个极差极用的一个声明那么就拿我之前举的那个OpenCruise和AgogoFlow为例其实我们给了一些样力的一些code来去做这个解析操作这里解决了一些部分然后对于ChromeSite为例的话大家可以看到左侧的一个interpreted replica其实就是提供了对ChromeSite这个资源对象去解析它的一个实力数以及它对应的资源然后对于非常多common的一个实现解析器内部其实封装了一些常用的函数方便用户来对它进行非常简单的一个自定义的开发对然后其实对于联邦来说我们处理的它对象其实就是一个像一个Jason这样的一个格式然后我们去根据这个函数式实现去解析它那么右侧的那个GreggisStatus其实就是提供了一个聚合的一个函数其实这个函数也非常简单大家可以看到它其实是把多个极群的一个实力数包括它的一个可以看到在联邦侧可以看到不同极群的一个总实力数包括ready的总实力数等等那么以workflow这个例子为例我们也提供了两个势力的一个方法第一个是一个return的一个方法它其实做主要工作其实就是当我们在那个对于workflow这种Status的这种资源来说我们希望它能够不会被成员极群所覆盖这样的话在联邦侧所覆盖这样的话成员极群可以顺利的step by step的像单极群一样的去运行这个workflow那么第二个interpreter health其实是提供了一个对于一个workflow这个资源对象我们如何判断它正常联邦如何认识它有没有执行完成或者它的一个健康状态这样的一个实现其实都可以看到代码是非常的一个非常简单然后让Edo呢对然后接下来是由张老师来讲一下那个vio的一些事件我来自vivo主要就是从事容器相关的工作今天的话跟大家分享一下就是vivo在多级学员方面的一些实践和探索首先的话跟大家介绍一下我们的vivo的容器平台就是我们的vivo的容器平台的话从2017年就开始建设了当初我们建设的话第一步的话首先就想帮我们的CRCD平台继续到我们的容器平台里面然后通过它发布的应用到我们的K8S继续里面这个是我们第一步想做的事然后第二步的话就是怎么去管理我们这个多级群的K8S首先的话我们主要是通过我们这个容器平台去做的第一点的话就是我们那个容器平台就提供了一个全新的导入功能然后就可以把我们部署好的那个K8S区域导入到我们的容器平台里面然后我们就可以去控制着我们这个K8S区域然后第二点的话就是我们实际上每个区域都是一个独立的运输独立的运行互相不干扰的为了将应用发布到我们这个K8S区域里面我们当初也继承了这种持续继承和持续部署然后也有这种监控和高点的能力的建设然后应用发布的时候我们肯定需要查询这些应用状态然后我们当初的话也开发了这种跨区群的这种查询还有这种IPI的聚合的这种能力这个一直持续到20202020的话就是因为我们的K8S区域用来多对于这种跨故障域的这种需求还有这种跨区群的这种大平洋的应用倾移的这种需求之所以我们在后面要调引了一下就是怎么去使用联邦职权去管控我们这个K8S职群首先第一点的话就是我们价格做了一个升级就是第一点的话我们的容器平台会对接我们的这种联邦控制的平面然后由我们的联邦控制的平面去管理我们这些K8S区域首先我们做的第一步的话就是之前已有的在K8S职权的一些服务实力就是我们需要帮它这种资源联邦化然后我们这样的话才可以通过我们这个联邦职群去实现统一的调度还有统一的发布还有这种统一的访问然后的话对于这种跨区群的这种很像的扩充能化我们这边也做了一些开发比如像FAT HPICHRON HPI这种能力的建设然后我们也测试了这种估计的这种转移这种能力这主要是我们这个容器平台它的一个发展的历程然后的话下面的话就跟大家总结一下就是我们在使用联邦职群的一个生产的必要的要素吧首先第一点就是集群的应为就是因为现在我们的联邦控制品面是管理我们的所有的K8S集群的如果它有问题的话就是整个集群基本上就挂掉了之所以我们在联邦职群控制面的话我们首先做了监控和告警然后还有左边的日治分析还有我们的控制品面的话也会做这种自制化的用为的这种控制然后对第三方插件的话比如像典型的这种OpenCourseUncleFloor的这种然后我们也做了一些集成和部署然后的话网络和存储这一块的话就是每公司的基本上价格都不一样主要就是比如说多级群这种网络是怎么去互联的还有这种跨集群的这种SoVS这种能力怎么实现的就是社区上面有很多方案然后还有多级群的这种Stories就是比如说我们现在用的都是基本上都是这种分布置存储还有数据的这种轻移数据的性能这种都是我们要考虑的下面的话主要介绍一下我们的容器平台就是跨集群的这种多级群的这种发布的话就是社区现在还没有一个统一的这种方案就是需要我们自己去开发比如说像跨集群的这种应用的发布比如滚动升级 回滚分批这种升级的能力还有的话就是这个应用是怎么轻移的比如说之前非联盟集群的那些应用如果轻移到我这个联盟集群肯定是也需要我们自己做的还有这种跨集群的这种减锁比如说没有发布下去我们要查群的那种状态怎么去查险 这也是我们要做的然后多级群的这种事件对一些高階用户的话它可能对KBS比较熟悉它就自己去开发然后自己去定制这些事件但是对一届低階用户的话它根本的不知道KBS的这群这里就需要我们做一些额外的这种开发比如说我们帮多级群的事件发到我们的中心键里面比如说RobinNQ这种组件然后它去消费去做一些查不出定和这种数据分析和这种决策然后整个控制的屏蔽的话这边的话设计队比如说卡曼达它已经提供了这种跨集群的调度从调度还有这种能力还有这种单级群的这种模拟然后多级群的权性的话基本上都是通过这种统一的群队的控制还有这种安全审计和监控这种能力然后跨集群的话就是HPF的话这刚刚说的就是就是一个跨集群的这种很像的库总统通常就是社区有这种FATHP和ChromeHPF这种能力去实践还有我们自己的比如说开发用手动库的这种能力下面的话就跟大家介绍一下就是怎么在我们的银芒区区区里面去集成我们这个OpenCruise首先的话跟大家介绍一下OpenCruiseOpenCruise的话就是一个基于开发S的一个困染的工具就是它主要就是负责这种大规模的这种应用的发布比如说像布鼠丸这种升级还有一些运萎还有有孔用性的这种保障在Vivo的话就是我们主要用到了两个资源第一个资源就是ConcetConcet的话之后主要就是进行这种无状态运动发布然后Odewallset的话就用有状态的服务发布然后的话在我们容器平台的话基于这种OpenCruise这种连芒区区运动发布的话我们主要做了下面的一些能力的实现比如说像分批升级还有这种滚动升级的这种能力还有这种回滚比如说就是远离升级还有这种升级可用性还有升级可力度的这种控制还有就是我们自己也开发了这种控制器去在比如说山厨或者是升级的时候不让它的流量不中断的这种能力的开发还有指定这种泡的山厨限制升级的速率的这种控制主要是在临芒区区区区实现它第二的话我们如果在林邦区区区里面去集成我们这个Open Groups呢首先的话第一点的话我们肯定是希望在我们这个林邦区区区区比如说我去get这种concept这种资源的话它应该是一个多级权的一个汇聚的状态怎么实现呢首先的话就是第一点的话就是我们需要在林邦区区区区区庄安装我们这个concept的concept CRD和Wallon's CRD因为我们现在只用了这两个CRD这次给我们首先只要在我们的控制品面去装这两个CRDCRD就行了第二步的话就是让我们在这种MEMO机群里面去装我们这个Open Groups的然后第三点的话就是需要我们在林邦控制品面去定义这种资源解释器比如说像Allemance Devletide和concept主要都通过这种LOA这种脚本就是无情用物的去写然后去进质这样的话就可以帮这个下面两个机群的状态汇聚上来然后的话我们就可以在我们这林邦机群控制面就可以去盖他到最终的状态的话是我们下面两个机群汇聚出来的这主要是如果在林邦机群里面去集选这个Open Groups的一个介绍然后下面的话就是我们能介绍一下比如说你在林邦机群里面如何去发布你的应用首先的话第一点我们肯定考虑比如说你发布你的应用你肯定需要考虑很多资源比如说像一些普通配置比如说像Common Mac还有一些密钥配置或者是一些服务发信这些东西如果设计到存储的话肯定你要考虑出来了这是第一点然后第二点的话就是你要帮这个林邦机群就是帮这个机群联邦化首先你需要再创建一些Kamala的一些策略比如说像Paxxon的这种这种策略就是需要帮这些机群联邦化联邦化之后你这个机群你上面的机群才可以被林邦机群这种调动和分发这样的话才可以分发到每个机群里面去然后第三点的话就是你需要你注意比如说一些差异的话的配置的话你这里肯定就需要使用这种OY的Prosy去实现比如说像比如说我发布就是云林升级其中就一个机群我只要更新一个机群的一个级面机的机群我其他机群不更新这需要这种OY的Prosy去实现比如说像还有它这种提供的这种Paxx的这种OY的这种能力我们这里可以用这种回滚升级或者滚动升级和分批次水击升级还有这种颗粒度的控制还升级送级的控制这样的话可以控制每个机群的这种升级送级都可以去控制的上面的话就是主要准备了三点就是在林邦机群发布的时候你肯定需要考虑三个方面一个是你自己本身的KBS机群第二点的话就是卡巴达的策略是怎么去创建的怎么管理的你需要做一个具体的了解下面的话我就跟大家分享一下在林邦机群里面我们如何去做一个分批次去发布的一个KBS一个案例首先的话就是比如说我这个服务就是它A机群里面有三个升级B机群里面也有三个升级比如说比如说滚动升级的话就比较简单了就是我们直接在林邦控制屏面去去更新一下我这个对象它就是每个机群就会变发地去升级滚动升级比如说像这个是滚动升级的参加然后比如说是分批次升级的话比如说我现在要更新机群Adder一个十年然后再更新机群B一个十年然后发现没问题的时候我们在所有的机群都帮它升级一下它怎么实现呢首先用户肯定的话肯定是通过我们的CSD平台去配置的比如说我需要升级机群Adder一个十年然后提交给我们的中级平台然后我们中级平台会打包这些人资源是去更新我们这个控制屏面然后去升级这里的话因为涉及到一个差异化的配置之所以这里我们肯定是会使用到ORI Proceed去实现它首先第一的话就是比如说我们现在升级第一个机群的一个十年首先的话就是在我们的ORI Proceed肯定会要指定这个机群然后里面的配置的话我们需要配置这个PartitionPartition的值的话我们这边replace价值那它会为i就是比如说Concet我们说i然后它就会升级第一个机群的第一个十年然后用户去check如果没有问题的话它再考虑升级第二个机群的第一个十年然后的话我们配置也是一样的我们用了ORI的去做差异化配置然后的话我们就可以在第二个机群里面去升级升级的指定的卡斯联盟然后设置的它的Partition这样的话我们就可以控制到第二个机群就是升级一个服务十年最终用户的话它自己就判断这个流量结入是不是正常如果正常的话它就这边没问题的话我们就需要这里就可以直接指定Cassey和Casby然后我们的ORI Policy的话直接就本来是为您这样的话它就会群一样地升级下面所有的服务十年这个主要跟大家分享一下联盟机群是如何去分批次子去升级可以通过我们ORI Policy这种策略去分批次子去升级上面的话主要是介绍了一下就是如果在开发资这个联盟机群里面去进行Open Cruise还有第二点的话就是我们这个联盟机群的应用是怎么发布的然后第三点的话就是跟大家介绍一下比如说我们这在庭业务是如果清理的比如说我们之前是非联盟机群管理的就是说这些服务我们怎么帮它清理过来这个的话社区的话也没有有接口去提供但是需要我们结合平台去实现它首先第一点的话就是就是说我们容器平台会有一个Babynanum的机制比如说我们这个CNCD发布的时候如果我们要确认你需要帮这个服务轻易到我们的Command上去管理的话首先第一点你帮这个服务加到我们这个Babynum里面去然后第二的话就是发布平台的话发布到我们的容器平台然后我们去查看这个Babynum如果在Babynum里面我们就认为它需要被轻易它轻易的话就是首先第一点就是我刚刚说的就是需要帮那些资源提交到Command里面去需要提交到你帮机群里面去实际上第一点就是你需要构建你一个capacity里面第二点的话就是你需要构建你一个Command的策略然后帮它提交到Command机群里面去然后你的应用就被烂关了就是如果你是不在Babynum还是走原来的一个发布机制这样的话最终对用户来讲它就是无感制的这样的话就是一个孤独的决单最终的话肯定我都会轻易到Command机群里面去的然后跟大家说一下我们的轻易策略轻易策略首先的话第一点的话就是我们有测试预发这种生产环境就是我们保证我们轻易的过程肯定是最好就是无让发生的这种保证业务这种平稳的这种轻易过去首先定的话我们肯定是从测试环境开始去轻易然后再轻易到我们的预发最终轻易到我们的生产然后第二点的话就是每个环境的话我们也是按照这种禀易的方式去轻易的比如说第一批次我轻易20%然后第二批次再轻易20%然后第三次我去轻易这种70%这个节奏去轻易然后在轻易过程中我们肯定是业务双方都要去顶紧的比如说我们去观看我们的监控是不是有问题业务是不是正常运行的没有问题的话我们肯定再继续轻易下面下面一个服务那最后一点的话就是就是确认它如果没有问题的话我们就可以认为它轻易没有问题的如果我们轻易过程中发生问题的话我们肯定会涉及到一个回轨的侧面就是为什么需要这个回轨侧面就算因为我们要保障这个业务轻易整个流程都是一个流畅的不要走在运用户的这种发布或者是影响运用户的正常使用首先第一点的话就是比如说在我们轻易的过程中发生错误比如说你的资源值轻易了一半还有一半没轻易这种情况出回是你的APS骑的有8个这一点然后第二点的话比如说就是发生一些位置错比如说在我们卡帮的控制平均发生一些位置错导致我们下面的MEMOG群出现异常这是第二点实际上这一点的话就是实际上卡帮的控制平均的话和我们下面的MEMOG群的话是最终的沟通的主要是通过Exception Controller去沟通的就是比如说负责它下面的MEMOG群的创建更新 删除 都这通过所以我们在这边只需要走断它跟下面的MEMOG群的联系的话就可以阻断我卡帮的控制平均和下面的MEMOG群的这种关系下面的话我给大家说一下比如说我们一个应用在轻易过程中发生的错误我们应该怎么做首先第一的话是肯定我们是要在我们的这个白名单机制里把这个应用给踢除掉然后我们在我们的过程中去打个助解然后的话我这个Exception Controller感觉到这个助解的话我这边就不做对底下的这种MEMOG群不做任何操作比如说像更新 还有删除这些操作我都不会去做这样的话就阻断了然后最后的话就是应用的话就可以去走原来的脑的方式就可以去发布我的应用就保证整个溜程是通畅的最终的话肯定我们都期望全部都轻易到我们的MEMOG群上面点这是一个固度的阶段下面的话就给大家总结一下就是底底的话就是在我们的MEMOG群中如果是去接线我们的OpenCourse然后第二点的话就是如果在MEMOG群中实现我这个发布然后第三点的话就是对于这种非MEMOG群如果轻易到MEMOG群的这种轻易侧脸和回更侧脸的介绍然后的话大家看有什么问题我们可以先讲个东西谢谢大家这个问题是关于就是前面有一个Motivation的一个问题就是您提到用ARGO Workflow的时候会有两个antity同时update的resource是这样的吗这个沈天真说一下对 是这样因为ARGO Workflow它这个CRD有个特殊的地方就是它的Status它不是一个字资源那么对于我们发布下去的一个应用来说其实你可以认为我们联邦是区分不出它是一个状态的更新还是说是一个比如说一个配置像Spark的一个期望信息的更新那么比如说正常情况下我们单级群里面它保证这个Workflow能够正常进行下去的前提就是它的状态就是它第一个step的状态它能够顺利执行那么在放到联邦化里面去发现的时候就会我们会发现联邦它会去覆盖这个状态因为它不知道这个Status是是不是它的一个状态还是说是一个正常配置信息的一个变更你说就是Federation Set的Controllerupdate那个resource的时候是把权量全过update了对 正常其实我们主要是针对于Spark信息和一些mata data的一些label annotation这些因为我们要保证联邦的控制面和我们产生集群的Workflow的一个sync同步的一个过程对 然后Aggroflow它是一个特殊的一个对象因为它这个Status它不是一个Status资源对于我们来说其实它可以认为其实是放在和Spark这种是一个期望的一个配置那有一个follower就是为什么那个资源不把它Status不做一个资源呢对 这个可能就是上游社区的一个就是一个设计的问题这个我们也在上游其实也和一些Aggro的社区有一些有一些提问一些合作吧但是这是属于他们设计其实我们还是希望能够不侵入式的去就是如果说不是他们出现的一些当然重要的问题我们是不希望去修改他们因为我们也希望给用户的体验也是对于那些原生的一些CNCF项目我们能够直接签过来用而不是说你要改改原来那些你要用Aggroflow你要改它的东西或者说你要OpenCruise你要改它的控制器什么的我们是不希望做到这一点那这会不会是一个Contribute to Aggro AppStream的一个机会对 其实我们和Aggro社区有交流但是可能现在推进速度还没有那么快吧对好的 谢谢好 我想问一下关于多级群的实力资源分配的问题比如说我们的广告面就是发配一个资源然后它有6个实力假设我们当前两个级群的资源比例是一样的那么我们6个资源正常的期望值是3比3的资源往下走的这是我们的一个期望值当我们第二次发布的时候假设我们下面两个Member Cluster分别是A和B当A的资源用得多了B的资源我扩展了那它的实力数可能会调成1比5这个应该是Kamena本身的调度能力计算出来的那么这里有一个问题就是当我A级群缩容的时候B级群的实力并没有起出来那么这会就会造成一个问题我们不是都说有个浪用吗所有的WalkerFuller队有浪用的处理那么在这个时候我们从原来的6的实力数可能会瞬间变为4的实力数对于一个生产级群来说它的流量4可能就扛不住那我想问一下这个种问题是如何解决的我描述清楚我的意思了吗首先第一点的话就是关于那个级群的那个比如说字面动态的时候导致发布的时候比如说之前是3比3的这种概率有可能会导致这种1比5的这种概率这个的话你可以用静态调度的方式去保证比如说我就设置它这个调度是3比3的这种概率说那就带了一个问题了你A级群有两个实力起不来那你再下去的话你还是3比3那你的整个的流程就会阻塞了这因为它资源不够嘛对吧我来解释一下这个问题就是你刚刚提到那个缩容的场景我理解那个后面的一个资源比率是根据当时级群的一个实时状态计算出来对吧对的然后其实我们在但是你的整个资源对象它有一个期望的一个实力就是它是不管怎么带哪个级群分它是能够希望能达到那个实力数的对 总量不变因为你的外界流量的期望值是不变的那其实你这种场景其实流量其实并不是均衡的状态我理解就是它不是比如说它这个service它对于每个级群的不同的一个对于一个end point它来说它其实它不是均衡的 是这样的吗你可以这么理解就是对于每个end point它是均衡的但是它的流量入口是一个总入口它根据你当前的泡的实力数你可以理解为它是每个泡的是均分的对 是那其实我理解就是不管我们在多级群里面我们以为你意思是在实力变化的时间那一段时间里面它会存在一段时间的一个服务质量下降的问题是这个问题吗是的对那其实我来解释一下就是我们正常情况下我们在实力的一个变更过程中它其实是会根据当前的一个状态去做扩容还是缩容就是它不会是说把所有实力全部都清掉然后再重新布所以说其实本质上比如说对于你这种情况来说在当前它的实力所有的同时那个集群它其实也在扩当然我理解会有一个短暂的一个不可能的时间就是这样下降的时间但总体上我理解是可控的我明白你的意思就是我A集群在缩容B集群在扩容吗对它是一个相对改变的过程而不是说先把它清到零然后再往上所以我理解这种问题应该是可控的对那我再把这个场景扩大一点我把6个实力变成100个实力然后同样是刚才的场景比如说我就换成10和90那么这个时候缩容这个东西它是没有额外依赖的但是扩容这个东西即使你资源够它也有一个服务的注册流量的预热以及其他的问题那就意味着你的缩容肯定比你的扩容快很多很多那就会瞬间调实力数对于你当前的这个服务而言其实对于这种情况我们现在社区其实也在做类似的特性就是主要就是针对避免中断这种情况下然后这种情况下其实在特别在缩容的场景下我们可能会先把实力先稳定住然后比如说一些非摄控的对于用户配置的这种信息来说我们可能会去让它做一些这种配置因为有些情况下其实用户是用户是希望达到这个地方的对这个后续可以继续关注一下行 好了你好 我也有个问题就是我刚才看到你们是跟用OpenCruise的CloneSet的Partition来做分批的 是吧我看到那个对 是的那我有个问题你刚才有6个破的你一个破的起来以后那就是一个新的和5个旧的就是流量至少是20%的新打进去 对吧对是不是太大了这个力度可能我这1%-2%去做这个金丝雀场景这个力度的话就是OpenCruise里面会有这个控制的就是比如说你也可以做那种拽钮比如说在删除的时候会是升级的时候会设置那些力度你可以去控制就看你这个比例是怎么控制的这个能控制流量比例吗 不行吧我就说是服务的实力的个数对啊 那你一个新的和5个旧的那至少是1%的新流量打到新实力上去至少是6分11了 对吧对那我可能是1%的流量那你怎么控制这个流量呢这个的话那肯定要跟你这个应该是跟你这个流量的控制的力快有关系吧就是我下面整个控制服务实力但是那个流量控制的话应该是其他的一些图件去控制它这边不管这个是吧这个的话就是也有但是我们这个公司里面也有这个这一块的流量控制的这个图件去控制它对我还有个问题就是Vivo现在的多机群联邦的是几个机群啊一般是我们机群的话挺多的大概是几个机群一个联邦下面有控制几个一次发布下面几个机群一般都是两到三个 对那我有个问题啊比如说我的机群比例是1比2比3就是我加进来一个是我加1比2比3比4这样子对那我这个比例怎么走就是当前比如说100个破的我是1比2比3在那边发布的对吧那我第四个进来以后我怎么样前面的怎么说下面的怎么上你是这边怎么做呢怎么样控制这个比例呢怎么让它折我要的比例上去呢这个比例的话就是我们那边会有一种就是比如说你第一次上线的时候我们会配这种静态的比例比如让你帮对是静态的比例那我还是100个破的那我前面的1、2、3怎么说上面4怎么上你这边有具体的一个步骤去做吗还说你只是让它自己走那你可能实力数就不到100个了呀或者超过很多了会有这种情况呀你说比如说缩容的时候或者比如扩容的时候有可能是超过100多个是吧是这个人多尽吗就是我加了心讯进来嘛现在我需要是4个集群1比2比3比4的比例吧那我这个前面的怎么说我前面的说多少个后面的起多少个你肯定先起再说嘛对吧那我前面起多少个后面说多少个你这边1、2、3怎么说你这边有具体的设控制吗这边暂时没有但是我们有OpenCourse的就是身体的颗粒度可以去控制它比如说深层一个或者是两个这样的话就保证它整个的稳定性这样子的因为可能我们再用感觉问题还挺多的对不好意思那个时间控制一下你们可以私下交流一下我们下一场的时间快到了不好意思那好的谢谢今天分享到这里谢谢大家