【云驻共创】边缘计算的前沿,更好的边端协同

举报
龙哥手记 发表于 2022/08/25 10:39:33 2022/08/25
【摘要】 从各前沿技术出发更加细节剖析边缘计算发展方向与背景,底层技术实现,详细说明边缘计算痛点与未来规划,共同完成并实现全链,全栈,全面赋能发展目标;

主要内容有

  • 一 DM软件设计与实现
  • 二 大规模的测试实践
  • 三 一致性测试是咋样
  • 四 SIG Testing介绍与规划
  • 五 分布式协同AI实践
  • 六 机器人的发展趋势与挑战

一 🎯 DM软件的设计与实现

1.1 背景及目标

物联网设备庞大,设备海量数据难以处理,而不同设备通讯协议,模型,传输格式众多,安全难以维护,目的是打造下一代云原生边缘设备管理标准;举个例子,如何避免用户恶意上传数据,来防止用户非法获取其他边缘网络权限而导致破坏呢?另外缺乏对设备状态的监控,最后就是KubeEdge Summit上手难度很大,因为需要自写操作设备的软件这个就很难;


你看上图第二点,比如走两条路,一个是edgecore,一个是Mapper下发这条路,这个本身存在问题,因为挂载web站点是放在prod里面的,因为K8s机制的原因里面prod是更新比较慢的,并且ETCD里面还要存一样就是数据冗余,Mapper会订阅ETCD会造成广播问题,还有就是监控不是完善的,数据通道也不是很灵活只有MQTT不是很方便的。

1.2 CMI架构是咋样


把这个DMI分成Eedge与Cloud,这种模式就像K8sCSI,CMI插件,做成标准入口,只要Mapper定义了DMI接受的接口;这里Mapper不局限于协议转换的Mapper,更多是LOT平台也行;然后Mapper通过MQTT协议接入

设备管理分成管理与业务两个方面,管理的数据走黄色可对接kubeEdge里面,业务走蓝色去发给数据处理的云原生应用,后面可能提供框架一键实现Mapper与DMI定制化连接

上图第一条,第二条是边缘侧应用通过restful Service去拉设备数据,3,4,5,6就是推数据,采集好后通过地址推送,7.8了两调试是通过MQTT borker协议推送;边缘设备采集到数据需在边缘立即反馈,再去修改边缘侧设备状态;

1.3 工作流程示例


在DMI架构下设备的工作流程,在旧架构是kubeEdge启动,触发CLoudCore组件,然后边缘侧注册deevice与deevice Moudle两部分,图中顺序标注很清楚;

如何定义接口


第一个模块是Mapper管理主要针对协议,驱动程序管理;第二,三类Device针对业务进行拆分;最后是事件管理,对各个mapper,Device节点监控,这里列举接口定义,有些参数CRD定义出来的哈;

1.4 未来工作规划


上面是DMI的发布的三个版本,当前我们进度是在设备管理及mapper的demo开发,如果感兴趣可以在社区联系我们;

二 🚀 大规模的测试实践

2.1 先说背景


开展大规模测试需要定质量指标,这里复用kubedges指标,如下图;第二部分定义pod端到端启动时延,规定pod端到端除去拉取时间要小于等于5s,只有满足这些指标,才能支持多大规模;

在测试之前,用户kubeEedgs可自定义CRD资源,在K8s里面各个维度并不是独立的,比如说你在集群里面有非常多pod,service数量不可能太多,要结合具体场景来测试哈;

2.2 测试工具

  • EdgeMark(模拟边缘侧Kubedges)

    上图有两个集群,k8s-master用来部署EdgeMark,而第二个是被测试集群,Hollow会把注册码放在CloudCore地址上面,k8s集群就会自注册称为EdgeMark中一台边缘节点,如果模拟10万边缘节点,那就需要在k8s-master里面创建20万Hollow pod;

    这个工具会输出性能测试报告,吞吐量及QPS到底多大等等,我们看下部署模型;K8s采用单节点部署;CloudCore采用是高可用部署,每个副本部署在一台节点上,通过ERB暴露服务连接EdgeMark地址接入到ClouCore里面去;

    下面是主要测试参数的配置,是因为ClouCore是做消息会聚处理,所以里面有很多work,work协程数也是非常重要;

2.3 测试结果及分析


下面是pod启动时延,是pod创建到运行每个阶段运行参数哈,得出结论如下

十万边缘节点,百万pod是怎么做到的? 下面左边是普通k8s架构,它在每个结点都是有一些组件的哈


所以针对频繁网络断连场景,EdgeHub会重新发起WebService请求,元数据也会经过新的Controller做比较,减少传输带宽,用CRD记录版本号达到可靠数据传输

我们也会推出最佳实践案例,来帮我们在生产环境落地,有以下几点:

三 😍 一致性测试是咋样



3.1 kubeEdge一致性测试设计

3.2 为啥需要一致性测试

3.3 测试集构成

3.4 一致性测试范围

3.5 测试集标准

3.6 一致性测试架构

测试流程

四 🌈 SIG Testing介绍与规划



4.1 指标是否稳定

上面这些指标再长时间是不是出现异常,都会通过测试得知版本是不是稳定的

上面左边是结构,右图集成一些场景,网络高时延,带宽,丢失,CPU内存满载等场景;


4.2 边缘应用跨地区部署的问题


图里面有kubeEdge集群在云端,边缘节点分布在不同地方,明显看出边缘节点规模是不同的,第二个不同地域网络不互通,可能想在鸡群里面有一个私仓库拉取镜像操作,最后是本地节点能拉取本地仓库镜像不需要走公网流量;


看下图,比如有北京,上海与杭州分组,kubeEdge边缘节点分组管理特性,把杭州的边缘点添加到杭州节点组里面去,其他城市也是同样道理;边缘点会自动节点组加上label,就是图下方蓝色部分;右边是设置节点组参数,把杭州边缘点加入节点组;其他城市大同小异;


上图是边缘应用会引入CRD,里面有Workload Templetes,边缘应用所需要的模板;Overriders就是差异化配置的信息,里面有两种如上图;


保证一个节点组客户端分类访问Service images…后端,如上图,给出例子,杭州客户端通过service-range-nodegroup访问到hou后端肯定就是杭州pod实例;

上图是最后对特性概览,Edgecation这个资源有service,depoint模板,后者模板分别应用节点组配置,生成节点组所需要depoint版本,把里面noselect字段替换成节点组共有的label标签,保证depoint生成的pod落在指定节点组内

4.3 实现原理和设计理念


上图右边,Controller有消息通知的过程,然后根据EdgeApplications的增删改,controller会把变化同步到子资源里面去,这样导致子资源与EdgeAppcations的pod数量相同;

上图是整个特性与kubedge的联系,然后引入新的kubedge controller manger,这个里面就是上面提到逻辑实现;左上角蓝色是如何创建资源是类似的,这里提一下service templetes如何实现流量闭环,首先在EdgeAppcation里面加上service模板,然后生成range node-group,然后传给Endpointslice就上图那个路线;

希望给用户提供统一的运维入口,从而管理各地区的Deployment,你可以查看EdgeApplication来查看这个地区应用运行状态;第二个是扩展性,让跨地区扩展模型具有更通用性,后面支持滚动更新,可以用depoint滚动更新;

4.4 现状与发展规划


第三点跟kubeSatefulset Deployment一一样统一get就能看到视图,就知道边缘应用在各分组的状态是咋样;


Edged就是裁剪的kubelet, SIG Node就是围绕上面三个模块与其他模块交互展开的;


比如升级K8s依赖,原本修改版本号就行,现在要修改代码差异,下面是开发新版本的HDl来用于kubelet裁剪


目前裁剪的kubelet就放在上面仓库,后面升级K8S版本,只需要拉取新版本的kubeEdge就行;

五 🎨 分布式协同AI实践




根据上图,分布式协同AI与过去有啥优势,有下面三点优势,如下图



根据上面挑战,进一步了解尤其是开发者的痛点,探索可能解决方案,下面描述下痛点



我们会提供测试用例管理,统一了AI算法,场景等,并且这个lanvs这个框架会兼容更多AI范式,更多可扩展数据集,下面咱举个例;


上图增量学习减少上云数据量,他同时获得10%精度提升,同时感谢各高校与公司支持;




比如带宽不足风险,比如边缘设备如果全部传入云端,如波音每秒产生5GB,显然卫星与它带宽不够,云边协同可以解决;

举个例,联邦学习指不出边缘设备进行分析处理,这个可以很好解决数据孤岛;并且兼容主流AI框架;


上图我们建立云端知识库,对边侧任务进行学习,结果反馈给知识库并更新边侧操作,这样大幅提高准确度;

上面是分布式AI基准测试套件,接下来介绍SIG未来规划,如下

六 😉 机器人的发展趋势与挑战






针对KubeEdge的端边云统一管理,包括提供RobeSDK,可把应用分发到云,边或协同;开发出具体场景的SLAM与AI,还有就是机器人监控数据采集及训练;同时开发机器人的仿真平台加快机器人开发速度;




但是Serverless会引入新安全风险,比如按需计费,资源耗尽攻击,DevOps提倡敏捷与快速迭代,如下;

6.1 云原生安全现状




问题是边缘之间,边缘与工有云之间是互相割裂,另外边缘设备处在网关后边,并不具备公有云给它配置公网IP,多个设备处于多个NAT后面,那边缘侧没有负载均衡与治理;

可能有人疑问?上图几层在业界有成熟实现,是不是只需要最低层边缘隧道网络做出来,但是边缘计算不能覆盖所有场景,有了之前基础,才有边缘网络通信方案;

6.2 进展与未来规划

最后我们尝试集成成熟的服务网格方案,关于进展与未来规划

上图显示正在做及目标,红色边代表SIG Networking基本完成,其他是未来做,pod跨子网转发,容器网络划分,灰度发布熔断限流,动态路由等高级服务治理服务;

本文参与华为云社区【内容共创】活动第19期。
https://bbs.huaweicloud.cn/blogs/370132
任务3:KubeEdge Summit 2022 云原生边缘计算峰会(技术前沿论坛)

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。