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

主要内容有：

• 一 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.com/blogs/370132
任务3：KubeEdge Summit 2022 云原生边缘计算峰会（技术前沿论坛）