那接下来开始我们今天的那个议题分享然后我今天分享的议题呢是那个呃 揭秘那个呃 库博也那个非寝入式的那个流量访问避伐呃 可能听这个名字大家可能觉得不知道在讲什么东西然后接下来的话我们具体展开介绍一下然后今天的话主要是分呃 四部分来介绍吧第一部分就是我们做这个功能特性的一个背景和一个动机呃 第二部分的话就是我们呃 这个特性的一些设计呃第三部分就是简单介绍一下我们整个呃 特性的一个实现然后最后的话就是呃看一下当前的一个进展以及那个呃 未来的一些计划呃 首先看一下我们做这个特性的一个背景呃呃 我们知道就是说边缘计算的话通常的话就是说呃 它的业务分散在呃 各地啊然后每个地方呢 它那个呃 资源呃 就是设备的资源以及那个呃网络架构也都是不一样的呃 我这边的话可以举一个例子就是我们之前做的一个项目叫那个呃 取消省界社会站这个项目的规模也非常大呃 在全国三十多个省市都是有落地的呃 它的一个需求的话就是说呃 希望通过呃边缘计算把那个呃 省界的那个收费站可以高速的自由的通过而不需要人为的一个干预它这个业务的话就有一个非常明显的一个特点就是说它这个地域的特征非常明显就是在每个呃 地势的那个交界处呃 都会有一些呃门架然后在门架上去装一些呃 智能的摄像头这些摄像头都是有一些呃 算力的呃通过这个智能摄像头它会在上面部署一些像收费的业务或者那种呃 车牌检测的一些业务等等一些应用呃 来使这个高高速上的这个车辆那个快速的一个通行呃 然后在做这个业务的过程中就遇到几个问题第一个就是呃它的地域的特征非常明显分散到呃 全国各地呃然后全国各地的话这个呃 门架的话应该是有上万个然后第二个的话就是说它每个门架的那个业务量是不一样的然后每个门架的它那个网络的状态也是不一样的有的网络状态非常好呃 有的网络质量就非常差还有一个就是说呃 它在这个业务的实施过程中为了保障那个呃 业务的一个快速的一个分发然后它每个省市其实都是布了呃 自己的那个镜像仓库的呃 然后每个省市它呃 收费的应用或者车板检测的应用呃 因为那个ISV的差异它也是有一些不一样的呃 所以经济这个问题的话就说呃 之前的话我们采取的一个解决方案就是针对这些问题就是比如说它那个呃不同的那个门价上它那个节点的数量业务的数量不一样那我们传统的做法就是说我可能每个门价上布一个Department的然后指定呃 不同的一个副本然后真的这种网络不通就说因为它那个每个门价之间其实上是没有业务交付的没有那个业务的互访的但是那个在呃 K-84的网络中它是在统一的一个呃 网络平面里面呃 所以传统的一个做法就是说呃 它会每一个门价上的那个应用它会呃 部署单独的那个Service然后针对那个呃 应用的一个配置的差异的话就说呃之前的做法就是说我每一个呃 门价上去创一个Department的呃 有不同的配置不同的镜像呃 不同的那个呃 一些呃 差异这是我们传统的一个做法但这种传统的做法呃 会带来一些问题我们可以看一下就说我们为每一个地域 每一个门价去部署单独的配置 应用呃这样的话这个数量你是非常龐大的就说因为在一个门价上的它的应用的话大概是呃 六到七个了因为它会在那个门价上部署一些呃 像那个数据库啊像一些NX之类的一些应用呃 假如我们有上万个那个门价的话然后每一个门价上不同的应用配置它这样是一个成绩的一个关系这样下来的话就说我们可能会有呃 好 好就是几万个呃 地跑门的几万个色位子甚至几万个confinement这样的一个配置然后这样就是龐大的一个数量的话就导致一个问题就说我们之前在运萎的过程中就是会出现各种各样的问题比如说呃 这个配置配错了或者说在升级的过程中也很麻烦因为几万个要做一次全量的升级的话就是人为的去升级的话这个周期的话还是比较长的呃 就基于此的话就是我们做了一个呃 节点分组管理的一个功能然后看一下呃 在介绍这个功能之前的话就是我还是想简单介绍一下就是我们库威迹的一个架构啊 可能有一些同学呃 之前有过了解我简单介绍一下呃 我们库威迹的话就是呃 基于库伯南德斯平台呃 做的一个呃 边缘计算的一个平台然后这个库威迹的话主要分为这个呃 云边端三部分然后云上的话是我们统一的一个管控面我们有一个呃 可拉扣帐一个组件这个组件的话主要是那个呃 负责那个类似的卧池呃 库伯南德斯的一些资源然后卧池到的资源的话如果是变缘测的话它会通过我们一个云边的一个双向通道呃 我们这个双向通道的话是支持那个呃 WebSocket 或者 Quake 协议然后也是支持那种呃 联合扩展的然后在变缘测的话是有一个 AGCOAGCO的话可以理解为是一个呃 轻量级的一个库伯奈德斯的一个组件我们对库伯奈德呃 做了一些裁检来适配那种呃 变缘测的那种资源量比较小的一些场景然后AGCO的话主要是负责那个容器的生命周期管理就是应用的生命周期管理这样一个功能它和那个云上的可拉扣会做这个呃 双向的通道的连接然后在端测的话我们呃抽象了一套DMI 加上那个DeviceMaple这样一套机制然后DMI的话是统一负责那个呃 设备的那个消息的一个转发那个数据的一个收集上报然后针对不同的那种物联网的协议我们呃 提供了那个Maple的一个框架可以让用户呃 根据自己的那个需求去开发对应的那个Maple然后我们社区的话也是目前有呃 有一些那个Maple已经在那个官网上比如说像那个ModelBusProticeOpsoA等等然后这样的话就可以把我们这个云边端三部分就做一个打通呃好的那个接下来看一下我们这个呃 节点分组的一些核心能力它的核心能力的话主要是包括三部分第一部分就是那个呃 节点分组节点分组的话其实这个呃 从概念来说就是说呃 根据这个节点的一些地域的一些分布的一些特征根据它的一些呃 资源的一些特征等我们会把这个节点做一个分组的一个管理然后第二部分是就是呃 针对边缘次这个应用部署的一些痛点我们抽象一个AZ Application这样一个workload来满足就是说在这种跨地域场景下来部署呃 和运为变成复杂的一个痛点然后第三部分就是呃 流量避防避防这一块然后流量避防的话呃 本质量就是说因为在跨地域的场景下其实大部分场景下就是说呃 这个业务的话一般部位做一个跨地域的一个访问一般都是在比如说我呃上海的一个门架的话它其实它的业务流量应该不会访问到就是说杭州那边去所以它一般就会有一个呃 很明显的一个特征就是会做一个流量避防其实我们这个也是基于那个呃 K-Bus 的那个 Service去做了一定的那个特性的一个开发呃 接下来看一下我们这个呃 特性的一个整体的一个呃 概览这个概览的话呃 其实使用我们这个特性其实呃 主要包括三部分第一部分就是说呃 你可以根据你的业务特征呃 边缘节点的分布来对你的那个边缘节点做一个分组然后在分组的基础上的话就是你可以根据我们这个抽象的这个AD Application去部署你的那个边缘的工作负载然后第三部分就是说呃 就是你在部署那个边缘负载的过程中呃 会创建那个 Service那个 Service的话它会根据你的那个呃 那个节点的一个特补做一个流量的自闭环呃 这是一个概览接下来我们会详细介绍一下这个三个部分呃 首先看一下这个节点分组的能力呃 这个真的这个节点分组的话我们试试抽象的一个API呃 通过那个Kubernetes的那个 CRD的机制我们抽象了一个叫呃 Notegroup 的这样一个API然后这个AP的话API的话就是呃 可以通过呃 指定那个Label 去删选对应的节点也可以通过指定那个对应的那个节点的列表比如说你有几个节点也可以通过这个配置写进去这样的话就可以把这个节点做一个分组的一个管理这里也有一个势力比如说我有杭州 北京 上海三个那个地域然后在这个地域里面部署了自己的一些业务然后通过我们这个CRD的话就是说花飞好这个节点组之后然后会没会给每一个节点打上一个呃 对应的一个标签就是说就是来分别表示它是属于哪一个节点组然后这个API的话也是比较简单呃 第二个部分就是那个AD Application这个也是呃 基于那个Kubernetes CRD也去呃 设计的一个API呃 这个API的话其实核心的部分呃 主要包括两大部分第一个是那个Walker Load Template呃 第二部分是那个Walker Load Scope呃 先看一下这个Walker Load Template的呃 其实这个里面就是说呃 你在部署边测应用的时候会用到一些应用的一些模板比如说呃 像DepartmentStiffle Set还比如说像Service Configure Map对 然后我们这个呃 Walker Load Template都可以去呃 做一个试骗呃 它是一个通用的一个模板然后那个针对那个不同地域的一个差异的话我们呃 有Walker Load Scope这样一个概念这个Walker Load Scope的话呃 它可以就说比如说你某些地域有一些差异化的配置都可以配在这个呃 Walker Load Scope里面然后这个Walker Load Scope里面其实也比较简单第一个就是说你先指定你要部署到的那个几点组的一个名字可以通过这个呃 弄到Gorup子弹来做一个指定然后接下来的话就是说你可以通过这个All Rider去呃 那个写一些你你的一些差异化的一些配置然后目前的话我们只是比如说这种ReplyTest All Rider就是说呃 副本化的一些差异就是说你在不同的地域可能呃 那个应用的那个配副本的数量不一样就可以通过这个All Rider去做一个呃 差异化的配置还有那种Imager All Rider就是因为有些场景可能需要呃 快速地去部署可能就会在本地去部署一个镜像仓库这个时候你就通过可以通过这个Imager All Rider去呃去配置你的那个镜像的一个差异呃 之后的话其实我们还有会更 增加更多的一些All Rider来支持就是说呃各种的差异化的一个配置呃这个图呃就是展示了一下这个流量避缓的一个呃 概念就是我们在通过那个AD Application在部署这个应用的过程中的话就是说你在填写那个Service那个Template的时候可以给这个Service加一这个加一个Annotation就是这边下面有标出呃 你如果加这个Annotation的话就说它这个Service的原数据在分发到各个节点组的时候它会做一些呃 相应的一些过滤然后你这样部署好之后比如说我有两个Notegov一个北京的一个上海的我这样的话就可以通过呃 一个Service来进行管理但是它的流量不会去跨区域去访问它会只会访问呃 那个呃 本区域的一个POD这样的话 其实一个是减少那种嗯 跨区域 跨地域访问的一个网络抖动第二个就是呃通过这种机制的话也可以减少那个云边那个消息传输的一个带宽呃 提高一个更大规模的一个管理呃来讲一下就是我们在设计这个特性的一个出发点就是我们希望通过这个特性的话第一个就是希望能够呃针对这种跨地域的一个应用的一个部署达到一个呃 统一的一个部署和运萎呃没有这个特性之前其实我们在取消省界上其实呃也遇到了很多困难比如说就是在呃下发运用以及在管理这个节点的过程中因为面临这个旁的数量我们就是非常的一个繁琐比如说你要呃查询一些department的信息查询一些节点的信息对吧对这个节点做一些维护的话这个数量非常绑到然后有了这个特性之后的话其实我可以通过这个ad application对这个跨地域的这个应用做一个统一的管理同时这个ad application它会对你那个跨地域的那个应用的那个状态呃做一个上报一个汇聚通过这一个ad application我们就可以把呃跨地域的所有的这种应用的当前的一个状态以及它的一个运萎做一个统一的一个管理其实节点也是的就是说之前节点的话其实呃我们缺少一个批量操作的一个能力之前比如说对节点做操作就是要呃比如说kubectl或者API做每一个for each做这样做这样操作有了这个node group的话我们可以通过这个node group这个对象对这个节点节点组里面的节点做一个呃统一的批量的一个管理呃第二部分就是说我们这个特性是那个可以灵活扩展的尤其在那个ad application这个层面因为我们通过那种呃sdrag的一个结构来屏蔽那个底层字源的一个差异就是说呃你可能有除了name problemstaffostaffo side可能还有一些自定义的一些资源都可以做一个灵活的扩展呃还有一个点就是我们这个流程其实和那个原生的那个kvas的那个资源的流程或者说你第三方的offer rate它这个流程是没有偶和的然后这样的话就可以就是说呃我会带来一些其他的一些比如说和那个kvas的原生组件呃呃那个互相改召这样一个问题然后最后一点就是我们希望通过这个特性可以最对这个呃别人的应用做一个大规模的管理其实通过我们这个之前的话也有一些客户已经上量这个量级也是蛮大的就是通过这个的话呃呃它有两个优点吧第一个就是我们减少了一个云边传输的一个带宽呃减少了对那个kubernetes apso的一个访问的一个压力来支撑一个更大的规模第二个就是说通过聚合的一个状态来减少对apso的一些请求的一次数在之前的话可能你需要呃分别调用相应的apn去查这些应用或者节点的一些状态现在我们通过这个有聚合我们有个operator他会去握持这些资源然后自动把这个状态做一个汇聚减少一个对apso的一个请求接下来看一下我们的一个实现的一个机制呃这个node growth的话其实实现比较简单就是我们可以指定我们的那个node growth上一个对象啊我们有两种同学第一种就是通过那个match levels第二个就是直接指定那个节点的列表然后你创建完这个对象之后然后我们有一个组件就是在clarkl里面叫node growth controller啊他就会去动态的去list watch这个node growth的这个资源当他这个nodewatch到这个资源之后他会根据你的配置去把对应的那个节点去打上对应的一个label去标识这个节点属于对应的一个节点组同时的话他还会去把属于这个节点组的节点的一个状态做一个汇聚然后去更新到这个apso里面这样的话就是通过这个node growth你就可以查看你这个节点组里面所有的节点以及节点的一个状态减少了一个延维的一个干预这些过程全部是自动化的接下来看这个AGA application其实AGA application其实刚才也讲也是一个CRD的一个对象我们通过配置这样CR一个对象比如说在这个视频里面其实我们有一个刚才也说有一个叫work load template的一个对象比如我在这个Spark里面配了就是incs这样一个对象然后它使用的那个进象的那个版本是最新的一个版本然后我在这个work load的scope里面我可以指定一些差异化的一个配置比如说我在这个杭州里面我可以篡改它的副本书是2然后它的那个进象仓库的地址也可以做一个差异化的一个修改然后北京这个地方的话我的副本书是3然后它同样也可以对进象的地址做一个差异化的一个修改当你创建完这个ad application之后然后我们对应的那个ad application control里面这个组件也会去动态的去握持这个资源然后它握持到这个资源之后会根据你的那个work load template和那个work load scope去生成那个最终下巴的一个应用的一个模板然后比如说它会把这个template scope做一个那个比较然后那个生成每个region的对应的一个配置比如说这个department它会根据这个work load scope应该生成两个department的那个配置然后去做一个下发去下发到对应的一个节点组然后这样同时的话就说它也会去把这些下发的这个资源的那个状态也会做一个会组我们通过这AZ application就可以对多地域跨地域的这个应用做一个统一的一个部署运萎以及一个ppp操作然后最后介绍一下我们那个流量避缓的一个实现的一个机制这个的话就是我们在cloud code的话有一个dynamic control这样一个组件我们知道的话其实在原生的那个list watch里面就是说每个节点都需要list watch比如说service in the point的这些资源因为那个kbox是一个扁平的那个网过嘛然后这个资源的话因为是要下发到所有的节点然后在边缘场景下其实是不适用的然后这个在规模比较大的这个场景下其实这个service in the point的这个分发其实会给这个集群带来很大的这个负担然后我们在dynamic control里面其实实现了一套那个数据过滤的一套框架通过这个框架的话就说可以按照你自己定义的规则对这个数据做一个过滤像这个流量避缓的话其实我们是做了怎样一个规则的就是我们会把那个下发的那个in the point的这个数据做一个过滤就说它会根据你下发的那个节点去反查对应的那个节点组然后只会把属于这个节点组的这个in the point里面那个PoldIP给下发下去这样的话一个是减少那个下发的一个数据量再一个就是说减少一些不必要的一些跨地域的一些网络访问我们这个右边的话也有这个例子就是讲这个in the point的sales这个filter到底做了什么事情我们可以看一下比如说有unique service这样一个service它对in the point的讲说有四个比如说杭州有两个泡的北京有两个泡的然后通过我们这个filter之后我们在变测比如说这个杭州这个节点组它只会收到属于这个节点组的那个PoldIP只剩下杭州的泡的一和泡的二然后北京的话它只会收到属于北京的这样泡的一个IP对然后我们这个数据过滤框架是电影了一套接口然后用户也是可以根据自己的需求去做一些灵活的一些过滤其实在我们的客户中比如说顺风今天下午我们有顺风的一个案例分享然后它管理的规模因为非常大然后他们内部管理的话其实是有自己的一套管理机制他们是这样做的就是会把这个节点其实通过Name of space做一个逻辑上的一个划分然后他们就可以通过我们这个filter去实现自己的一套数据过滤的一套机制然后通过制造机制的话其实可以很大程度上减少一些不必要的一些数据的一些分发减少一个云边带快的一个使用然后看压这个特限目前的一个现状和我们相远的一些计划目前的话我们是支持就是那个Application目前的话支持Department, Service, Configure MapsDefault Set等等然后流量避缓这一块我们也已经做了然后目前的话就说资源的状态和汇聚的话其实支持它不是很完善后面的话我们还会支持更多的状态的一个收集后面的话我们也会做一些演进比如说Application这个APN的话会根据那种别人的场景会做进一步的一个细化同时的话我们还会提供一些友好的一些用户界面用户的命令行的一些支持来去更好的去使用我们这个特性对以上基本上就是我所演讲的那个全部内容然后这有我们Gatehub一个仓库的一个地址以及我们那个这个特性实现的Cave的一个地址然后我们Coupage其实也有很多那个落地单位也今天没有讲我们在下面有展弹如果感兴趣的话也可以去展开去咨询一下先我今天的演讲就这么多大家有什么问题可以讨论一下你好我请教一下就是刚才我我看见你讲就是说是这个边缘节点的那个铺的IP它其实是由这个云端去下发的那这样的话就说如果我的边缘节点之间的铺都想去做通信的话是不是可以支持是不是大概是怎么做到的这个方案这个在同一个那个节点组的那个铺的都是可以互访的就是我们只是把跨地域的这种不必要的这种铺的IP给去除了因为在很多业务场景下这种一般不会存在这种跨地域的如果你需要这种跨地域坊比如说杭州的北京需要访问你可以把那个就是说对应的Adentation给去掉就可以了然后在同一个节点组的这种跨节点访问是没有问题的这个就是必须依赖于这个节点就是云端评评的IP才可以是这样是可以这样理解吗我们这个云端刚才那个它只是把这个对应的那个Interpolar做了一些过滤就是说把属于同一个节点组的那个炮弹的IP就是过滤到一起然后把不属于这个节点组的IP就不需要给这个节点组下发因为我不会去访问别的节点组的那个服务吗明白 谢谢老师 这边还有一个你好 谢谢你的分享我问两个问题第一个就是说你那个Adge Application的那个定义里面是不是可以包含就是一系列的APP还是就一个可以包个多个可以包含多个对第二个就是说你这个Adge Group是不是都是互斥的就是不会存在着有一些节点它是可以在两个组之间共享那种目前的话我们是一般的应用场景是没有就是说跨节点组的这种场景就是目前落地的一些案例因为它从那种地域上来说我们目前还没有遇到但是我们目前这个节点组目前也是不支持就是说一个节点属于多个节点组长一个场景的就是说你必须给这个节点一个明确而且唯一的一个分组对您好 我想请教一下就是在这个每个Edge Core上面每个Edge Node的上面都有部署Edge Core对吧Edge Core跟Cloud Core之间他们是需要有互相访问的能力对不对对只需要Adge Core可以单向如果能向上访问通就行那Cloud Core是怎么去访问Edge Core呢因为这个通道就是这种WebSocket Quake就是它这个连接建立好之后我那个云上其实就可以通过WebSocket的通道去往下面发消息所以其实就不需要每个Edge CoreEdge Node都有一个共网IP之类的通过网关这样去访问也都是可以的也是可以的好 谢谢行 如果没有问题那我这边就先这样好 谢谢大家