好 谢谢大家今天我跟宋阳一起为大家合奖Kmash是一个架构创新为East2带来一种新的数据面选择OK 首先介绍一下我自己我那个是徐中虎然后我的GateHub ID的话很多人都见过就是杭州HZ然后徐中虎然后我现在来自于华欧云然后我这边是华欧云的一个研访然后我也是East2带来一种新的数据面选择然后我也是East2带来一种新的数据面选择前一际我在Kmash的公园里面工作然后我也是一个Kmash组织者Kmash 抱歉在2023年我预备了Google Open SourcePIA Bonus AwardI co-authored《云原生》服务网格East2和East2权威指南这两本书好 宋阳大家好 我介绍一下自己我叫谢宋阳然后也是来自华欧公司然后我这边主要是对操作系统然后服务网格有定律的学习然后现在是Open OLA高兴能网络随格的Maintainer然后EBV的Maintainer然后今天带来的这个项目Kmash项目的一个开发者和那个主要贡献者OK然后首先我们看一下服务网格这块的这个尤其是East2原来我们的Satikard这个模式然后这里主要是聚焦在Resource and Latency然后看一下我们East2这边主要的一个Satikard架构大家都想必来到这里的人我想大家都比较熟悉这种模式我们是East2的控制面这是现在East2D然后从开始到大概是从1.6合并之后吧然后East2D这个叫单体的这个控制面一直就到现在基本上没有变过的最开始的1.6之前我记得大概是1.6啊如果说记错的话大家可以纠正我就是在1.6之前实际上是有三个组件的有Pilot然后Gally啊还有Citadel对然后1.6之后是只有一个控制面是只有一个组件East2D然后East2D然后管控着所有的SatikardSatikard就是每一个炮的中就注入一个Satikard的container然后这个有container去拦截然后并且去路由啊附带均衡啊我们应用发出的流量然后整个部属模型呢是大概是这种样子的就是我们在控制面这个East2D是不属在可能是在我们的管理面的节点上面然后如果大家为了高和弘一般会在自己的服往阁中把这个East2D然后不属在跟自己的业务容器是隔离的一些节点上面然后呢上面这个图里面就是所有的我们的业务容器业务容器会被注入一些Satikard如果我们我们如果需要的话就是可以去让它去注入然后当然也有一些选项一些annotation去让我们去选择对一些应用不注入然后右边的这个图中呢是我们East2D社区里面对这个Satikard模型去做的一个performance test然后这里的这个图是在自社区1.19这边最新的一个测试然后我们可以看到在1.19中呢一个proxy大概消耗是0.5的VCPU然后呢可以处理这个1000的RPS这个是社区的一个测试的一个结果然后也可以看到从这张图中啊也可以看到我们这个整个试验然后如果是在这种模型下面就是Client and Server都有Satikard的这个条件下然后我们这个East9增加的试验是大概是一点就是90%的试验的话是1.31毫秒和99%的试验的话就是1.58毫秒然后右边这张图其实也能看出来我们East9去有一些就是因为很多人去做做这个性能测试的时候会有一些默认的一些配置如果我们去做优化的话比如说去掉一些不必要的这种Felter啊它的性能是会提升的从这个上下两条线大家也可以看到就是有一些做可观测性的Status啊那种Felter就是把它关掉之后它的性能是有提升的再来看一下就是其实很多人或者有一些场景啊对这种识言啊或者是Satikard的这个资源开销是有一些介意的对然后我们看一下就在一些开源社区开源领域啊有一些项目其实做了一些探索比如说East9我们这边有一些探索比如说基于EBPF加速啊就是把本来蓝节能部分然后换成本来IPDBOS蓝节能部分用这个EBPF来做蓝节然后减少了协战的开销然后还有一些比如说Celium这边我们Celium其实知道也发布了自己的Celium MeshCelium Service Mesh应该是它也是S的话直接走的这个内核的这边处理而7的话但是它又绕回到这个它的拥护态拥护态其实也是基于这个应该也是一个基于Involve的一个东西Celium Involve然后还有一些这个Poxelis的就是把它提升到LDK里面的业方案比如说GRPC然后还有毛孙啊这种其实也是支持这种Poxelis的另外林克蒂其实最开始其实也是有一些探索的林克蒂这边他那边当然基本上现在算是在这块其实在这块性能方面林克蒂他本身原来就是跟Involve这边设计他这个有些区别的他的扩展性啊其实没有Involve这边好所以说他林克蒂这边他本身的Latency可能因为他功能也没那么多嘛所以他的Latency可能稍微会好一点点对然后下面一个就是我们去分析了分析了一下当前Sidecar它的性能的开销的一些点还有我们自己的想法然后通过这个火焰图我们分析出来我们现在看到Sidecar去通信的时候它这个实验都消耗在哪里边大概是这样的就是这个用户态和内核态的context switching大概花了25%的时间然后这个ProtocolStack就整个几个Stack它是花了大概40%的开销然后这个IPT-Balls这个转发呢大概是耗费了是10%的这个时间然后这个SidecarTraffic的这个HideJack这个HideJack是啥意思呢就是我们从这个流量到Envoy在Envoy处理到路由之前这个阶段我们叫这边取了个名字叫TrafficHideJack这部分是大概花了15%然后后面的15%就是包括Envoy的Routine还有它的LoadBalance这一块大概花了另外的10%所以说我们是做了啥呢我们是做了一个想法我们的想法就是说我们想做一个这种透明的然后高效的还有低开销的这么一个服往格的技术设施然后这边这个模型呢也是大概的一个思考最开始其实是有一些shared library model就是我们现在JRPC那种模式就是有一个共享的直接在SDK里面去做这个流量的字体这个是比较老的还有另外就是SDK那种传统的模式然后后面的话眼睛倒是Satica然后我们的新的想法呢就是有一个把这个Satica这块的能力然后下沉到offload到操作系统的内核里面然后在内核里面通过这个内核的能力去做这个流量的这个字体工作这就是我们的这个基本想法然后下面呢我想请我的同事这个谢宋阳然后为大家展开一下我们这个Kmash当前这个做的一些探索好 谢谢忠虎我给大家介绍一下那个Kmash在这块做的一些探索就是前面忠虎提到的当前的服往格其实在一些高性能的场景下其实有一些限制嘛所以我们在这块也做了一些尝试主要分为两个阶段嘛第一个阶段我们是基于这个SoccerMap就是可能一些其他项目也有一些基于这个技术点做的基于就是SoccerMap对现有的一个Satica架构的这个网格做的一个数据面的加速然后还有进一阶段我们又做了这个四到七层的流量治理的这个offload就是下沉到内核中去做这个流量管理这个是刚才讲到的第一阶段做的这个基于SoccerMap做的大家可以看到就是左边这个图左边这个图那个因为Satica的引入嘛就是它引入了代理架构其实是引入了这个进出内核协战的开销就是下面鸿框标注的这个地方那这一块能力我们思考是其实是可以通过EBPF的能力来做一些短阶和加速就是下面这个TCBIP协战部分内核协战我们其实是可以用EBPF来加速的这块主要的那个技术点就是基于SoccerMap就是社区的这个EBPF的一个指特性它能够把这个Soccer的力度的这个流量做一个Node上面的一个短阶这块的话我们做了一些这个Banchmark的验证包括一些功能的开发最终是能够达到短到端的的话它是能够有个15%以上的一个性能提升如果单看PoD到SatKa之间其实提升效果会更高一点就整体的话从PoD发出流量然后经过本端的SatKa然后再经过SoR的SatKa到最终到SoR这个路径的话是有个15%的一个提升那整体来看的话SoccerMap其实对现有的网格这代理加构是有一定的加速效果但是可能有一些极端的场景或者说一些对性能要求更高的一些场景能不能进一步减少实验的开销所以我们又进一步做了offload的一个探索这个是我们近期做的一个Kmash的一个主要功能就是看左面这个对比图的话就是原来的SatKa它是一个代理加构它其实从Service A到Service B之间是经过三跳就是三条链接它本身客户端要给自身的SatKa建立一条链接然后做一些流量编排的一个能力然后SatKa到SatKa之间它的通路也有一些旋路 旋指 路由的能力然后到Service之间其实也要经过一层代理整体来看的话它其实是把原来的服务访问的一跳变成了三跳所以实验开销是增加比较明显的然后我们Kmash的思路就是把编排能力下沉到内核当然这里面是用到了EBPF的技术还有内核可编程就是我们提供了一个流量管理的软碳膜整体的话是达到了三跳变一跳的一个效果就是下面这个图这样的话就是说我从Service A到Service B它能完成一个在内核协议站里面一个随流的一个治理其实一跳就完成了这样达到一个目的就是达到一个目标就是没有额外的晒哈文切换没有用戴到内核带的额外的数据考备然后也是达成了五代里的一个通信模式这里面是具体的一些细节就是说展开了一下我们在Hip Performance下是怎么达成的这个目标整体来说的话就是刚才讲到的基于EBPF还有内核的一个可编程的一个软碳膜这块达到的最终的效果是能够达到L4到L7的一个高性能的治理具体来说就是我们在流量渐连的阶段是引入了一个伪接连的技术这个是在我们的软碳膜里面的一个增强的功能就是实际的话是把那个渐连的实际推迟到了新的Message阶段这样的话在SendMessage的阶段中我们其实是能够拿到L4到L7的一个全站的信息这样的话拿到L4到L7的全站的信息其实我们就可以做七层的一个编排四层编排可能社区的业项目已经做了就是说可能好实现一点那七层的话其实是用到了我们核心的伪接连和延迟建设的技术最终的话达到的这个效果就是把这个编排治理的这个逻辑下沉到操作系统中就是Offload的那个可能中达到一个高兴的那个目的这边是一个那个部属模式的一个对比就是原来我们这个Sataka的部属模式其实是PiPode的模式嘛就是每个Pode或者每个容器之间它要有一个半成容器Sataka来做一些编排的一些工作那现在的话我们其实是把这个整体的编排的这个能力下沉到Kmash其实就是内核中做成一个随留的一个代理或者一个编排那其实是没有额外来开销的相当于是这块应该是有一个70%以上的资源开销的减少当然对比的是一个典型的Sataka的这个部属模式这边也是我们做的一个能力增强了一个能力相当于本身Kmash这一块是支持对接一侧到地就是支持标准的XDS协议它控制面是支持一个平滑切换的一个能力然后另外的话因为EPV它本身可能是有一些限制一些能力我们也在逐渐构建整体的话大家可以根据那个自己的业务场景来选择因为它本身对内核版本就是EPV能力对内核版本也有一定的依赖刚才讲到的两个点一个是我们基于Sataka Map的加速就上面这条线它其实还是现有的这个基于现有的这个包含隐外的代理架构做的一个加速比如说大家的业务有些比较复杂的编排逻辑或者说我现在对自己的架构不想有太大的改变还是想要Sataka模式的这个部属架构那其实可以用Kimash这个Sataka Map加速能力大概有个15%到20%的提升另外的话也支持大家如果是有一些高性能的场景可以把我们的服务通过一些配置来部属成无赛特卡的部属模式它本身的话可以走Kimash的一些编排能力就是说我既兼容了这个高性能又兼容了一些比如说附带均衡 汇渡 路由这些编排能力达成了一个高性能的编排的逻辑对 这是这一块的内容这是一个规划的一个能力就是一个全站的可观测能力服务网格它其实比较关键的还有一个是可观测这块我们把流量治理下沉到内核之后其实是可以做到一个短短的全站可观测比如说我们克兰德多安斯沃端的一些指标的采集包括服网格的一些指标采集可以统一上报这一块是有一个短短端的指标采集的一个功能然后有一个细利度的观测然后还可以做一些EBPFGBPF的一些流量力度的探针另外是可以对接主流的一些观测平台就是Promius 卡法卡这些都可以支持一些标准协议的上报对 这个也是我们近期会构建的一个能力整体的KMAS的一个能力的概览先看一下左边这个图左边这个图刚才有讲到我们其实是支持标准的协议就是e2D可以平滑对接然后你的控制面如果是支持XDS协议也可以去很简单的适配然后下面这一层我们是做了KMAS肯州的就是做了一个XDS协议的管理然后EBOL程序的管理然后可编程的一些逻辑然后还有一个观测的能力然后中间是有一个KMAS API就是做一些转换包括把一些用户态的一些信息一些模型转换到内核里面的EPF模型主要的数据面的功能在下面这个KonoBase里面这里面是分为两块一个是EPF的能力这块是有一些基本的编排包括路由 负载均衡 挥度是在这里面做的然后包括一些指标的采集然后一些数据的指标的采集一些监测也是在这里面做然后下面我们也提供了一个Runtime就是一个编排的一个基本能力里面做了一些刚才讲到的延迟建链 伪建链的核心功能然后还有这个协议解析的一些能力整体的几个特性的话就是右边这上面的几个一个是平滑的对接因为它是对现有的一些数据面是可以做到兼容然后还有一些XDS的一个标准对接然后还有一个高性能高性能的话是有一个将近60%的一个实验的提升就是消耗的减少然后还有一个低负载低负载的话就是从部署模式来看的话是可以有效的减少这个CPU和内存到这个底噪下面的话就是也是一些能力吧就是一些XDS的一个开源的一个对接能力然后包括一个POD的力度的安全能力还有我们汇许规划的一个全站的可观测这边是我们的一个测试数据选了三组场景来测试最上面这个是那个Kubu Proce就是紫色的这一块是相当于没有走赛达卡就是单独走一下那个KBS原生的这个服务访问是作为一个对照组基本对照组然后下面是有一个赛达卡模式中间这个一次到这个银翁A模式去做了一个第二组的一个对照然后最下面是我们KBS的这个能力主要是对这个路由加鞋解析加RB这一串能力做了一个基本的验证可以看到右边这个折线图它其实是有三条线但是可以看到那个KBS这条线和KMS这条线是基本重合的而且说明在做这个编排的同时KMS它其实能够做到一个基本上是没有明显的这个消耗增加的这个性能然后赛达卡的这种模式的话它随着这个并发出的提升其实它的裂画还是比较明显的所以就是说KMS它最终达到的效果就是说我把这个流量编排下成了内核之后基本的这个编排路由能力在兼容的同时然后没有带来这个性能损耗这个是一个demo的演示我看一下没出来是不是放不出来行 那个视频可能暂时打不开然后这个在我们社区里面也有相应的数据大家感兴趣的话可以看一下这边是我们路标的一个规划就是我们现在支持的能力是有这个路由编排的基本的Runtime这个能力然后支持HTB 1.1的R7是支持这个R4和SoccerMap其实不区分的然后还有一个路由的能力一个灰度发布的影能力还有一个基本的RB的影能力那个近期的话我们这两天也会发布一个就是刚才讲到的多数据面结合了这个配合的这个能力就是说大家可以按需来使能我们的SoccerMap或者是那个Kmash的这个offload的能力对 那个年底的话会发布一个可观测然后明年上半年的话是有这个线流和这个容断的一个能力然后还有后续的一个透明透明传输的一个能力对 这是我们社区的业信息大家感兴趣的话可以加入到我们的社区包括一些讨论组整体的话我们的项目叫Kmash对 谢谢大家这信息大家需要的话可以关注一下谢谢你好 我有个问题就是那个刚才讲到Kmash你那个数据进Kernel那那个你从Application到Kernel到另外一个Application最中间那条连接有Terminator吗就是你会在Kmash那间把它Terminator 然后重新建一条出去吗不会的就是一个forward 是吧对那如果是Application发出来一条是TLS的连接在Kmash这边有什么特殊的处理吗稍等一下这个地方是主要的一个编排逻辑吧就是刚才说TRS场景对TRS场景这一块刚才在路边里面有提到其实这一块我们也有思考就是说TRS的能力这个可能它会依赖一些标准库 对吧一些建连这一块我们后续会把这个流量做一些导出到用户态去做控制流的一个建连然后再把流量导进来就是我们可能是对主要是对数据流加速控制流的话还是要走一下用户态就是Handshake那部分还是在对好 谢谢还有个问题就是如果跨Note的话那个Kmash和Kmash之间是MTLS吗还是当前的话当前的话它是走那个默认的容器网络嘛就是我们MTLS的能力还在构建好 明白后续的话应该还会走MTLS好 知道 谢谢前面下一个选后面OK 感谢分享那个我想问一下那个就是offload到内核之后的话那个内核这边怎么去实现这种多珠所谓的多珠就是说那个因为我们要做L7的那个协议的解析嘛对假设这个Note上有多个APP对吧然后项外发请求然后有一个APP它假设它那个协议就处理耗时比较长然后会不会把其他的给饿死了它这个其实就是说EBBF它这个能力它是通过可编程是植入到内核的就是我们这边是在那个内核的一些关键节点包括这个Connect或者SendMessage是挂了钩子来实现这个能力它本身的话是一个随流的就是说你是迫得力度的你这个迫得发这个消息过来之后就是它本身它也要走内核协议站嘛这条路其实在这条路上做了一个随流的编排就是它不是一个其实我想问的是那个就是有一个APP然后它比如说Trubug对吧它一直在发请求使凶函那比如说它一直在发那里内核就肯定一直在处理它对吧那其他人是不是就处理不过来了就这个意思你类似于故障隔离这一块对对对这一块首先它EBBF它是有一些教研机制嘛就是说你本身可能就是它你这个编排的逻辑基本上它是认同于是内核代码本身是有一定的可靠性或者安全的这个保障然后那另外你说那个不停地发消息对吧把内核协议站打爆或者这种对对对这块后续我们可能就是结合我们的可观测可能我们那个因为EBBF它可以做到一些系地图的一些观测就是随流的一些观测那我可能要做一些指标的采集和商报包括我后续可能会把它熔断了或者可能要做一个反馈的这种机制就是后续这个能力也会构建好 理解一下谢谢然后就想问一下那个内核的版本现在是最低版本是多少内核版本其实我说的我们这个能力它是分几块就是那个SoccerMap其实社区的4.18 4.19就是跟着这个社区的这个版本走就是你可以选择把SoccerMap就是说你Satakar这种场景就是不用offload的这种场景是可以使能的然后R4的话其实就是5.10就是社区的5.10是可以支持的R7因为我们是有一个软弹幕的增强这一块其实我们有一些派纸我们也会归等然后后续在社区也会对一些主流的操作系统版本可能会做一些适配然后去发布出来所以总体来说就是说大家可能要结合自己的优长艇来按需来使能其中的部分功能好的 谢谢感谢我补充一个点明天这个K-MAX实际上在这个展区是有个展台的大家了解更多的细节的话可以去展台那边对 刚才那个DEMO没播出来嘛大家在展台的进一步了解一下我想问一个问题就是说现在我们是有一些七层的一些处理会放在内核里面去做吗对通过EPF去做是那假如说我在做一些高级的七层的一些处理的时候就是这个流量治理的时候那我是不是我在内核里面都能实现跟塞卡一样的这样的一些效果是不是说我还能还是需要经过塞卡的一个处理才能去解决一些比较高级的这些流量治理的一些功能成绩这一块其实我们做L7的时候也有这个以后嘛因为它EPF其实是有些限制的大家也知道所以我们这边是提供了一个看一下针对L7的话我们是右下角这边是最下面是提供了一个编排的运营室可能做了一些内核的增强这一块是我们本身也做了路由 挥度然后还有一些这个解析的一些功能的开发现在其实已经上线了其实这些能力是可以的但是说高阶段的能力可能我们还要逐渐构建另外一个就是说刚才您提到的就是我们也支持这个多数据面协同可能你确实当阶段的功能有些高阶段的能力还不满足那可能选择上面这条路通过我们的SogMap能力来做部分的加速嘛然后你有些服务是走高性能的可能你是现有的这个能力诉求正好和Kmash当前发布的能力也匹配那你就可以走下面这条线当然那个我们做的也不是说完全把这个饮貌也或者赛代卡替代掉嘛就是说一个可能大家按需选择一个配合的关系最终是这个目标OK那一个小问题在就是说我们在协议这方面就说我们的支持是有一个什么情况现在协议的话其实RO7这边我们是当天做了一个1.1然后后续的那个常用的协议还在构建这一块多协议然后那SogMap和RO4其实是不区分的嘛就是可以这部分能力是可以用的谢谢好了那个我们今天上午的这个办场的这个就是结束了然后下面是那个Coffee Time让大家去喝点咖啡聊聊天交流交流然后那个10点50应该是10点50吧对吧我们这边继续开始上午的下半场然后那个大家注意一下那个Speaker能不能暂时先留一下然后我们有点事情