大家好,今天我们给大家分享的库伯看主题是如何高效管理数以万计的EDC集群我是今天分享者,谈从目前负责谈讯大规模EDC集群治理与稳定性优化动作我是今天的分享者王超凡,然后目前在同学们主要负责同学们大规模COVID-19集群管理以及稳定性的相关工作然后这是我们今天的分享的大干内容,首先我们将为大家介绍一下大规模EDC集群治理的挑战这一块我们将主要从韵文和内科片两大方面来介绍其实我们将为大家介绍为了解决这些挑战,我们设计实现了一个云元生EDC治理平台Castana一个剖析第三部分我们将为大家深入介绍一下我们的一个高级进阶版EDC operator的一个设计与实现最后我们将为大家介绍一下我们在EDC数据跨场复制和COVID-19特性方面两方面的大规模一些实践的一些经验首先是大规模集群的治理挑战,然后我们首先来介绍一下我们的业务背景腾讯营对外提供了TK1,EKS,ERG,MESH等丰富的云元生产品服务这些产品目前有300万的企业用户和开发者在使用他们在我们腾讯营上创建了数万的KBAS的全托稿和独立的集群,总集群规模数达到千万几同时我们也是国内首家对外提供EDC产品服务的云产生我们对内支撑了腾讯数百业务和数百业务的EDC需求同时对外也有斗予微盟等公司的网关注射中心等业务产品诉求正是源于在大规模KBAS集群下的EDC诉求和各种其他DPSL网关的一些EDC需求他们最终形成我们超大规模的EDC集群那么在治理超大规模EDC集群过程中有哪些挑战呢首先我将从运为篇给大家介绍一下我们面临的哪些问题首先当然就是集群的一个创建创建修改删除这一系列的操作了对吧我们需要一个高效的一个平台组建来实现这种快速的集群的创建修改等这样的操作其实我们需要一个强大的监控系统来覆盖我们线扇数以万计的这种EDC集群同时需要一个灵活的告警来帮助我们及时发现引范其次我们面临治理数以万计的EDC集群我们需要一号自动化的许减系统去及时发现一些引换点来帮助我们提高一系列的工作效率提升集群的EDC集群稳定性最后EDC是一个数据存储服务因此数据的安全性是至关正的所以我们需要一个灵活的强大的一个备份及恢复系统最后一点可能是很多云产产都需要具备的能力因为我们有很多EDC集群特别是我们有一些产品下需要做到一些多数户会共享EDC集群我们需要做到一些EDC热千亿的能力然后我再跟大家介绍一下为什么我们就需要许减这里我在跟大家说的我们其实我们要做许减的一个核心原因就是我们需要提高希望集群的一个稳定性那么提高稳定性从哪些方面找选呢当然是从如何搞挂一个集群开始对吧我们就把就把用户如何搞挂一个集群的一些残态一些一些因素做成一系列的许减的策略比如说业务规模特别大可以把集群规模特别大可能会导致他的EDC集群出现问题然后比如说他的异层的容量CRD,KammerMap或者议问特别多可能也会导致出问题然后比如说异层的读写KBS也会导致我们的集群文件出现问题再比如说我们的数据毁坏一些数据的不一致8个EDC也会导致我们整个集群出现严正的负责介绍完从应为程度介绍完我们的EDC治理挑战过程之后我们再从EDC内核维度介绍一下我们的一些难点首先就是给大家介绍的数据不一致我们发现了多个EDC数据不一致其中一个8个影响EDC所有的卫生版本然后其次还有内存泄漏死锁然后还有系列性能问题等的系列性能问题需要我们优化最重要是EDC它本身不提供它的一些KBS线索特性我们必须要从零到一来实现EDC的线索特性以及跨层农债一些方案的设计和实现面临以上难点我们就设计实现了我们就希望我们提出一个解决方案它能满足我们以下的设计目标来解决以上的问题首先这个解决方案我们有定下这四个目标主要是从扩展性高可用高效应为及治愈然后以及可观在性这方面来说扩展性主要是说的是我们不仅要支持KBS产警的EDC基金也要支持各种其他业务产警比如说API-6网关的EDC产警的它的一些管理诉求然后我们需要支持多种的一些千余顺化比如说VIA-V3,V3-V3,冷千余,热千余等等然后我们要支持多种调度策略比如说它解决的是EDC集群往哪里迁移的问题它可以保证我们线上EDC集群的熔炼尽量负载均衡不会出现过载的集群然后还有一点就是我们刚刚前面提到我们有丰富的询检策略我们需要保证我们即时去通过询检策略所以即时发现我们陷害了一些潜在的隐患点介绍完扩展性再看高可用高可用主要是我们EDC要具备跨可容区部署的能力然后以及具备垂直级水平扩动的能力同时我们还需要对EDC的稳定性进行一系列优化然后包括bug修发新特性开发等等现在后面我会给大家介绍一些跨场复制的扩展性就是这方面的然后第四点就是通过EDC的混沌工程测试来保占我们EDC集群的稳定性尽快尽早来帮我们发现一些bug等第三点就是高相域为及资予这一块主要是从我们的询检策略备份然后一些节点过程资予的方面来说第四点就是可观测性不管我们是集群管理还是集群SO集群迁移我们都希望做到有可实化的一个查看接下来私立目标之后再看我们的发案选型发案选型我们主要是有三大考虑第一个是开发效率第二个是可观测性第三个是可运为性其实我们最终看重的还是可运为性已经一个主线的资予能力像我们前面提到了有很多设计目标其实都会浅到这点KBS的破冷机制它现在就提供了一种机制来让我们实现一种operate机制让我们实现这种高度可运为可资予的能力的一些框架然后KBS本身它有破冷机制还有提供CRD和聚合API SO这两种发案支持然后CRD它整体来源部署跟使用的非常简单不需要部署额的组件然后这个对外开源可能比较合适但是对内我们使用的其实使用的是聚合API SO因为我们需要我们的集群规模非常大我们的CRD可能会非常多我们使用它来传出我们的EDC集群然后同时我们也需要我们需要我们的集群具备跨迁移能力平台组件需要灵活的迁移能力然后接上往我们EDC集群来致力的挑战之后我们接下来就为大家我们的EDC云圆森EDC治理平台Caston的它的一些核心特性这是它的正如大家说这是它的整体架构核心是有两大组件组成第一个组件是EDC class operator它支持多种class provider比如说传练的EDC集群然后开源的EDC operator然后我们系统自带的CastonEDC operator通过它我们可以实现通过业务文件控制台就可以实现秒极的串键EDC集群操作第二个核心组件就是我们的EDCEDC inspection operator它主要是负责以系列寻减策略的实现比如说以致性资源兑现速大K 健康度热点显请求这些策略的实现同时我们平台Caston还具备了一系列的飞鞋开关比如说监控废分智能总断当我们新建一个集群或者导入一个重点集群时我们可以通过一个开关机可以快速开启这些特性大大提升我们的开发运为效率然后这是我们一个可实化的外部系统我们可以通过外部系统对我们的EDC完EDC集群完成真杀改查操作然后这些系统也集成了可实化的监控寻减备份管理等系列功能然后这是我们基于operate的自动化集群管理然后先找起我们是基于Answerbot来创建集群的然后它的效率还整点也非常低的通过operate之后我们可以通过它完成集群的创建集群的扩缩络统一的纳管可实化管理大大提升了我们的效率然后这是我们Caston平台的一个核心CID资源EDC cluster它的一个specification从这个压抹文件中大家可以看到它下面描述了整个集群的一些特性的开关然后集群的吃饭大小吃饭类型然后吃饭的节点数吃饭的CPU和内存一些配置信息正如我们前面提到的它支持注册和已有和新增EDC集群并支持多种EDC class provided实现并都可以通过adaptation来控制多个废且的开关一键开启监控备份去健康询检一致性检查等特性极大的提升我们的运为效率然后这是EDC cluster status它的一个压抹文件从这个压抹文件里面大家可以看到它上面显示了各个节点的一些成员各个集群的成员节点信息角色然后节点的状态节点的版本号等我们不仅可以通过Public Control来查看整个集群的一些节点信息也可以通过外部可实化系统来查看然后这是我们集群的第二个核心的CRD组件询检EDC inspection CRD的一个描述它支持多种询检策略比如说前面提到的监控备份是健康询检一致性一蚕科PS一蚕资源兑现数等并且各个询检策略支持后种支持多种后端Provided实现向我们的监控我们可以支持PromiseOS也可以支持基于我们腾讯开源的KWAS水平口扣展的Provided实例比如说还有一致性你可以通过节点数来各个节点的K数来判断一致性也可以通过Ruptur相应的版本号来判断这是我们询检的一个结果试图这下面展示了我们对EDC业务集群的KBS询检试图可以看到每个资源兑现的一个反问的KBS然后EDC一致性差异询检下面是我们各个业务集群资源农联训练可以看到各个兑现的它的大兑现数最后是一个EDC的各个成员节点健康度的一个询检这是我们刚刚提到的大规模集群的监控解决方案KWAS它是一个水平口扣展的Provided实例水平口扣展的Provided实例解决方案这一点大家可以通过我们到时候可以通过我们的GainHub上一个开源项目KWAS来详细深入了解因为时间关系我就不在这里做深入介绍然后这是我们的数据备份方案基于EDC Backup Operator来扩展开发的我们支持将数据分众级备份到COS S3等对线存储然后这是我们前面谴调可实化的另外一个体现就是我们可以通过WebCon系统来查看EDC里面对应的数据尤其是KBS产品的一些KBI的数据它可以帮大家派出的了解当你在KBS上新增一个K的时候它是新增一个资源的时候在EDC中是如何存储的最后再给大家介绍一下我们EDC一个迁移任务的实现然后我们正如我们前面EDC Cluster和EDC Cluster和讯件的CRD一样我们在这里通过新增一个EDCMagration迁移任务的CRD它用它来描述迁移的原EDC目的EDC集群迁移算法以致性检测策略的第二个核心特点就是我们的迁移算法是抽象化的也是插象化的我们支持多种后装的Provider比如说EDC-V3V3-V3冷迁移 热迁移等第三点就是我们保证迁移的准确性我们具备多种维度的数据以致性检查策略比如说从EDC-EDC维度的数据以致性检查KBI是应用程的资源兑现以致性检查等等它可以保证我们迁移的万无一失确保数据不丢失最后一点就是纵连给和大家介绍一下我们在KBUS产品迁移可能会导致一些问题核心主要问题还是就是在迁移之后它的一个迁移后的EDC-EDC版本号是小于原有EDC这个会导致KBUS的一些Client科布顿Client会List Watch的时候它会撼住在面对这个问题我们通过修改KBUS的版本的原码增加Watch操作的Timeout机制来解决这是我们迁移任务的一个可说的查看然后这个迁移任务CRD和流程它描述了我们一个业务1178个节点大规模进行快速迁移的一个效果整个流程僅耗34秒业务几乎无感之接下来由王超环同学为大家介绍一下我们Kstone EDC Operator的一个设计和实现王超环同学已经跟大家简单介绍了就是整个Kstone的一个架构接下来我来给大家介绍一下Kstone EDC Operator的一个设计和实现首先我们来看一下我们的设计目标之前介绍Kstone的时候已经大概都介绍过了这里大家可以简单看一下简单总结一下就是我们需要一个具备高可行融灾以及支持很方便的继续弹线扩缩融在应用性上我们需要支持集群内外部的一个访问并且很方便的已经创建一个安全性的支持HTBS的一个集群并且支持我们平华地去进行一个证书的一个重签等等在可行为性上面我们要支持有我们经常遇到的一个集群升级等等还有一些自定义的一些参数修改等等融灾上我们需要支持跨动融灾然后以及EDCD本身3.4支持的一些灯耐节点等等可以说我们在扩容的时候更加安全看完设计目标我们最开始也调研了社区当前的一些实现方案主流实现方案主要有一下几种一种是基于安斯堡在物理机或者云主机上部署然后另外一种是基于Docker或者说Static Pod来进行容器化部署那当前设计师用比较多的一种是基于HarmChart来使用Staff Set部署比如现在各个主流的云产商他们都通过议用市场就是通过HarmChart来提供这种使用方式那还有一种就是基于Core S的EDCD operator进行部署Core S的EDCD operator是EDCD是operator的一个算是一个教科舒适的一个比组了那除了这些之外就是各个业务根据自己的特性去进行那些字眼那些EDCD operator来进行部署那我们对比了一下几种方案之后那我们最终选择了就是说自己去开发这样一个EDCD operator因为通过Ansebo,Docker或者说Staff Set这种Static Pod的这种方式来部署它有点是可听的话能力比较强也可以去进行一些参数的能但是在融灾和治愈方面就稍有不足了Core S的的话比较复杂那基于Staff Set因为它支持持续化存储它的高可用能力以及融灾能力会比较强一些但是由于Staff Set它每个副本的参数都是一样的那对于复杂的状态管理的话你可能需要在启动参数里去编写大量的脚本来实现管理然后在一些比较极端的场景下可能会稍有不足那社区的EDCD operator这种模式非常好但是它也是EDCD operator模式的一个B组但是当前的话在融灾能力上稍有不足对于持续化存储的话它支持有限你如果同时有一般以上的基点刮掉之后那这个集群就只能通过备份来恢复了可能会造成数据丢失那当前的话Core S的EDCD operator已经处于一个归党的一个状态了社区基本上已经不再维护了因此最终我们决定就是基于当前EDCD operator以后的能力去做一些进一步的增强在异用性和可用性的基础上我们来增强它的融灾能力以及可扩展性等等那最终就形成了我们当前的一个Kissed on EDCD operator的一个整体架构我们在整体设计上是参考了EDCD operator的一个思路然后统一的使用生命式API来管理通过自定CRD的方式来去抽象各个资源比如EDCD clusterEDCD备份以及EDCD恢复等等那相对于裸泼的管理我们当前是使用TPP来管理EDCD的泼的然后TPP相对于Clevel Set它更加的灵活除了支持Clevel Set原生的能力之外它还支持不同的POD可以使用不同的模板这样可以就是因为EDCD每个节点的启动参数可能会有不同我们通过使用不同的模板就可以去支持不同的节点的参数它还支持原地更新以及就是停止指定POD的能力等等并且在藤芯内部已经经过了大规模的使用和验证稳定性就有一定的保证那之所以不使用裸泼的是因为如果使用裸泼的话我们需要去更多的去关注就是资料存储的一些考虑然后如果直接使用TPP我们相当于把这部分的就是比如Color Case这些东西交给TPP来管理我们就更专注于EDCD的一些用逻辑那同时我们通过引入一个定命控制可以进行复杂的一些参数教验以及参数转换等等那通过资料的控制我们可以进行一些更高效以及的资议动作以及更复杂的因为操作等等相对于Stealth Set来讲的话使用上更加的灵活这个是我们EDCD Class的一个简单的一个CRD资料定义我们可以很方便的通过固定控制Apply一个压庙来一键的去创建一个EDCD机群那在机群创建的时候我们会通过每一个EDCD Class来去创建一个对应的TPP模板然后首先第一个套的它节点相当于是创建一个单节点的一个机群然后其他的新增的节点通过加入以存在机群的方式来加入然后在初始的状态我们会先启动一个Size是1的一个TPP然后在这个机群判立之后我们会将它的Size逐渐就是调整为就是跟EDCD期望的Size一样的复本数然后来进行这样达到一个机群初始化的一个能力通过更新TPP的模板来逐步达到这样一个期望状态那因为我们使用了TPP本身支持使用它存储因此在使用使用它存储时由于数据不会丢失因此节点挂掉重建的话就相当于只是相当于进行一次重启所以如果一个机群中同时挂掉一半以上的泡的只要这个泡的能够先建出来那么这个机群就是可以继续恢复的并且不会有任何数据丢失因此我们可以容认就是机群里边有超过一半以上的节点鼓掌那在使用非捷化存储的时候因为没有捷化存储那如果一个泡的重建之后它的数据就会发生丢失因此我们就需要将这个老的节点进行一个遗粗操作然后将它重新加入到机群中我们通过admin control可以在admin control里去做这个事情然后在一个泡的消费的时候然后如果是使用的非不是捷化的存储我们可以将它先移出机群然后从一调动的时候再加入到机群里边那这时候也要支持非捷化存储是因为我们有些场景可能会对性能要求更高比如我们的一些event机群之类的它可能对数据敏感性要求不是很高对数据安全性可能也可以容忍部分数据丢失但对性能要求很高因此我们就可以通过这是内存型的一些存储来提高这部分节群的性能同时我们这是通过配置清合性和反清合性来实现很方便的实现一个跨动容栽那除此之外我们可以通过指定lanar的一个index来指定某个节点作为lanar然后通过指定index之后在机群扩容的过程中我们就会将这个节点以lanar的方式加进来这样可以有效的避免就是机群扩容过程中然后因为某些破裸库的然后照上整体的一个机群不可用可以更平滑的进行一个机群的扩容然后我们再将lanar的index的移除之后我们通过control的reconcile可以将lanar来提升为一个member来实现平滑的一个扩容然后除了etc机群本身的高可运之外我们还通过支持冷卑的一些方式通过创建etc backup的方式我们可以备份指定机群到对象存储比如gcs,costs,s3等等然后通过创建etc disk到我们可以使用远程的一个备份来恢复一个etc机群或者新建议或者用eo的备份来新建议一个etc机群那在扩容方面呢我们通过最近的control然后去进行一个这样的一个reconcile来一个操作然后用户可以通过edit然后去更加它的side或者直接用couple control scale来达到一个机群扩容那个目的除此之外呢在应用性上呢我们针对就是安全性以及就是应用性上做了一些优化比如说我们支持密码建权以及证书建权我们可以自动的给用户去签发一个护端证书和扣护端证书等等然后避免了一些就是dcd没那么了解的用户在证书签发上面遇到了一些问题同时呢我们还支持证书的一个滚动更新你可以去更改这个extra server server的SN然后呢如果etcd control然后检测到就是你的域名有发生更新它就会自动去进行一个证书的一个轮转同时呢检测到pod的使用的证书跟这个最新的证书对不上之后它就会进行一个滚动的一个重进来实现一个证书的滚动更新的一个操作然后同时呢我们通过支持secret来配置这些建权信息来保证我们的备份以及恢复可以正常的进行那在进行访问方面呢我们支持就是通过进行内或者进行外去暴露这样一个访问方式通过annotation我们可以指定不同的service provider比如我们可以在进行内我们使用class IP然后如果需要暴露到进行外我们可以使用loaded balance类型的loaded balance这里我们也支持就是通过扩展的方式支持不同的provider比如GKE TKE AWS的呢然后最后呢就是我们为方便用为来进行的一个进行版本升级在进行进行升级的过程中你只需要更新一下就ADC Dispatch的一个class version然后如果是允许升级的版本跟运行扛车首先会教训就是这个升级是否合法如果解决合法的话就允许你提交这次升级然后ADC Dispatch扛车了就会进行这样一个升级操作然后最终将进行滚动升级到你期望的一个版本然后除此之外呢我们还支持就是你将已有的一个机群来平滑的切到这样In ADCD operator管理的一个机群然后通过annotation的方式呢我们可以去声明一个已有机群的一个信息这样呢在ADCD cluster它在扩容的时候就会直接加入已有机群的方式来去扩容节点然后扩容之后呢如果我们需要就是完全迁移到ADCD operator管理的机群我们就可以通过更新这个annotation来将老机群的node移除掉然后最终实现这样一个平滑的一个过渡然后用户在切换的过程中只需要在扩容ADCD cluster的过程中然后将方式切到operator管理然后再通过更新annotation来把老的机群移除掉之后就可以完成这样一个平滑的一个过渡然后不会造成业务就是损失OK这个就是我们整体的一个ADCD operator的一个设计然后接下来我们把时间机交给唐宗好最后我再跟大家介绍一下我们在ADCD数据跨程复制和QOS特性大规模实现上的一些经验和心得这里我给大家罗类了有五种解决方案然后翻译就是ADCD群本身多节点跨程部署翻案是基于ADCD linear节点进行跨程复制翻案30基于ADCD社区开源的MacMirror机制进行跨程复制翻案4和5是我们自研的跨程数据复制翻案然后翻案1鲁图锁设它的优点就是其实部署非常简单跨地域各地域网络互动之后部署过程不需要维护额外的组件同时数据跨程强一致同步可容忍任意层次固战不会丢失任何数据但是它的缺点就是毫无疑问你任何写请求都需要至少两滴硬打确认这会导致写性能急剧下降然后其实读性能也会下降因为ADCD默认都是现行读发挥节点收到Client发起读请求后它也需要先立的确认确认相关信息或许相关信息确认本地数据追赶成立的之后才能返回数据给Client这也会导致读请求它的读言是扇身吞吐链下降其次跨程的网络之内也容易抖动然后翻案就是GVDC LANA节点进行数据跨程复制核心就是在一地部署组织群另外一地部署一个背节点然后它的优点同样是部署维护非常简单你不需要维护二的组件然后LANA节点也可以同步类似的类型的数据k-value 健全数据等等然后缺点就是LANA节点我们知道它只允许串性读如果你业务想要究竟读的话那就会读到咱就数据其次像它依赖高版本的ECD比如说EDC 3.4G以剩版本才支持LANA特性并且只允许一个LANA节点最终一点是组继群全面固战之后我们没法快速将LANA节点提升为可写独立 EDC 集群然后翻案3是EDC 社区的它一个简易的Make a real 机制它的核心原理就通过EDC 的一个版本版本号机制去Watch它然后首先启动的时候它会通过range请求去获取权量数据然后再通过版本号机去Watch然后后面新增事件都会推送到Make a real 服务在同步给目的的集群它的优点就是组组 EDC 集群读写性能高整体上不会受网络延时跨地域延时质量波动的影响也业务如果业务可以农人短暂不一致它也可以读究竟的 EDC 集群也不依赖高版本 EDC它的缺点毫无疑问就是它的性能就是如果它的性能就是非常差为什么性能差呢因为当Make a real 团布连络中断之后它退出重启会再次进入权量模式无法满足生产环境的一系列诉求特别是C区自带的Make a real 工具缺少利的选举数据一致性检测日治Match等一系列特性还不具备生产环境可用性同时它也不支持同步Fake Value 数据为了解决Make a real 它本身的一系列缺陷我们设计实现了一个Make a real 加强版Make a real plus它实现了以下特性它支持多种同步模式的全联团布断连续传可以不用担忧装线跟完质量斗动等同时它具备高可用数据多维度的数据以制性检查像全联数据检查快捞检查都提供同时支持多实力并发复制提升性能还具备良好的运动能力等等翻误是我们基于基于类似于Lanage类似于DC Lanage 节点的原理来实现了一个同步服务它通过同步服务伪装成一个Lanage 节点加入主机群然后从主机群获取Rocket 日式条目让它在解析线日式条目转换成相应的TX inputDelete Range 的请求再转发对应的目的集群去它具备就是EDC Mirror Process 的所有特性和优点同时不依赖EDC MWC 历史数据同时它可以同步Range 类型的数据不依赖高版本的EDC但缺点就是它需要运动开发时间需要我们对EDC有足够的了解最后再给大家介绍的就是我们EDC的CoS 特性我们通过它来保障我们线网 EDC 集群的玩具性它的核心是有两大数据结构组成第一个是EDC CoS Class它定义了一系列的线素器比如说Token Bucket FairLeak Bucket Fair 等等每个线素器有对应的KPS 等等然后第二个就是它的一个CoS 规则CoS 规则的核心是由对线比如说线素对线是可以是用户可以是请求的路径前綴也可以是可能的IP其次是请求的规则描述了请求的操作比如说是Get操作还是Pool操作还是Delete操作其次是还包含K的前綴K的范围等等最重要一点它支持一个丰富的一些条件表示比如说它支持按你扫描的K数来触发线性的线素规则支持按DB使用率百分比来备满触发线性的线素器等等这里我举了一个案例就是E1产几的线素的配置这里我们给E1产几配置了四个线素器分别是读写正在请求的下来的CoS分别是二十每秒然后E1产读请求下是一秒一次E1产写请求下是一秒一次那么哪些是E1产读哪些产性是E1产写呢国家就是在于这个条件表达是这里我们罗内了四种条件四种CoS规则前面两种是正常情况下的一个规则后面两种是描述的是如果丹丁的一个读请求它上描可以大于一千的舍那它将执行严格的E1产产型的读线素规则也就是说执行一秒一次的请求最后一个就是丹丁的DB使用率百分比接近百分之九十也就是说即将要满的时候我们将给你触发匹配易产产品下的严格写线素也就是说每秒只能允许你写一次通过这样一套CoS机制它显著地提高了我们线上ETT集群的稳定性然后这是我们先往实现的一个效果这里配了几个Metress会包括一个集群里面被线素的请求数线素的CoBS每个集群的读写CoBS严实等等通过它我们来保障我们线上ETT集群的稳定性最后我们的分享就到此结束了谢谢大家