【摘要】 在18年时候,工信部发展了一个叫国家翻新倒退工程,这个工程中提出了要建设一个国家工业大数据中心,中国移动在其中承当了边缘协同与数据采集相干性能的研发。本文将从该我的项目背景下面临的问题与挑战、技术选型等方面进行论述。

一、问题与挑战

需要

从工厂采集生产、运行数据,汇总云端

云端进行对立管制:采什么数据、数据怎么解决

挑战

只能边被动连云,云不能够被动连边(边缘没有公网IP)

足够通用,灵便适应各类工业设施与协定

具备边缘自治能力,在网络不稳固时,边缘可能自治

具备边缘计算能力,可能在边缘节点运行各类利用

占用资源少,功耗低

二、技术选型

技术选型其实也是从咱们的理论需要登程的,首先是EdgeX,其实在做这个我的项目之前,咱们始终是用EdgeX做数据采集和治理的,EdgeX在数据采集和治理上做的还是比较完善的,性能也比拟强,然而它也短少一些能力,比方云边协同能力,我认为它是一个纯的边缘自治架构,不具备和云的一个同步能力,当然咱们也有一些计划,比方从EdgeX的节点上拨一个VPN拨到咱们的核心云上,然而VPN这种计划的扩展性还是比拟差一点的;

![上传失败,undefined]()

备注:图片来自互联网

第二就是K3S/K8S,K3S/K8S第一个问题也是不具备云边协同能力,第二点是尤其是K8s占用的资源太大了,不太适宜放在咱们的工厂,K3s占用的资源曾经少了不少,但一方面短少云边协同的能力,另一方面也短少设施治理能力;

第三个是OpenNESS,它是十分通用的框架,但对咱们来说太通用了,不管做什么,都须要写适配器,去底层对接Kubernetes都能够,有点太灵便,开发工作量绝对比拟大,不足设施治理的能力;

第四个是OpenYurt,这个从性能形容上和KubeEdge比拟像,但呈现的比拟晚,而过后咱们的我的项目曾经进行了一半了,目前看起来它整体的成熟度还是比KubeEdge差一些;

最初是KubeEdge。它具备云边协同能力、资源开销比拟小,它还具备设施治理能力,我认为它还是比拟有特色的,尤其是云边协同能力和设施治理能力,可能市面上很少找到同时具备这两种能力的。

架构设计

整体框架

这个是咱们理论在国家工业互联网大数据中心中用到的架构,其实最外围的就是咱们的KubeEdge,它其实就起到了一个设施治理、利用治理的作用;我的云端必定首先会有一个K8s集群,咱们会部署KubeEdge所谓的Cloud Core,所有的数据包含治理数据都是保留在云端的K8s中,边缘侧是运行在咱们所谓的工控机或工业网关上,它运行的Kube Edge的Edge Core过程,它是负责在边缘侧运行咱们的容器化利用,包含做设施治理、数据采集的一些利用;

Edge Core再往下就是Mapper,它是社区定义的一个规范,专门用来做设施治理和数据采集的,Mapper社区目前是提供了Modbus和蓝牙,比方我想治理一个摄像头,一个本人的设施,那我须要依照社区的标准去写Mapper,再往上看是咱们封装那一层,通过Java和Spring Cloud封装了一层治理服务,为什么要做这一层封装呢?如果咱们间接把KubeEdge或K8s的API裸露给用户,会有一些平安上的隐患,因为这个接口还是比拟凋谢的,可能波及到一些数据隔离性和K8s集群自身的一些性能,如果咱们一旦把这个API裸露,用户可能会做一些破坏性的操作,所以咱们对外还封装了一层业务逻辑。

最初咱们还做了一个工业APP集市,做这个的起因次要是咱们社区其实是定了一个规范,我集体开发者或者厂商其实我能够依照这个规范去做Mapper利用,做完之后它能够公布到咱们的利用市场,咱们能够免费或者收费分享给其余用户,其实这样咱们也是心愿建设这样一个生态来激励大家基于KubeEdge去做Mapper,心愿做Mapper的开发者也能失去收益,这是咱们的一个思考。

数据采集

咱们在我的项目过程中对KubeEdge的一些改良:

(1)反对更宽泛的工业设施与协定

其实咱们在刚做我的项目的时候发现KubeEdge反对的协定是无限的,只反对蓝牙、Modbus,而且它的CRD中把这个货色曾经固定了,咱们没有方法进行批改,所以咱们要减少本人的协定就很不灵便,咱们须要对代码层做一些改变,思考到工业上协定十分多,而且有些是公有的货色,所以咱们为了更好的反对这些协定,就容许做一些自定义扩大,一个是扩大现有的协定,比如说大家同样都是用Modbus协定,不同的设施可能有一些额定的配置,这个时候就能够用到咱们新加的CustomizedValue字段,能够自定义的去配一些字段;第二种是齐全就不必社区的协定,这个时候能够齐全用咱们的CustomizedProtocol,齐全自定义本人的协定。

(2)反对更便捷的设施采集配置

其实工业上和咱们有些IT思路还是不太一样,咱们做IT的个别是先定义模板,再定义实例,然而工业上有所不同,个别是先定义实例,将实例复制批改外面的内容,但其实他们这么做也是思考到现实情况的,举个例子,我有10个温度传感器,它是截然不同的,接到了同一个工业总线上,然而它所谓的属性都是一样的,惟一的区别是它在Modbus上的偏移量不一样,所以说我只有把Instance中的偏移量改了就能够了,所以基于这种思考咱们把原来Device model中的PropertyVisitor挪动到DeviceInstance中,而后也退出了一些更灵便的配置项,比方整个采集周期是不能够配置的,工业中不同测点它是能够配置不同的采集周期,比方温度中周期可能是一小时一次,那像能耗数据可能就不须要这么高的频率了,所以这就须要一个更灵便的采集周期的一个配置,咱们还做了减少CollectCycle等配置项到PropertyVisitor中以及抽取串口、TCP配置到公共局部。

(3)优化孪生属性的下发

(4)反对旁路数据配置

旁路数据处理

反对Mapper推送时序数据至边缘MQTT broker(EdgeCore不解决),具体推送到哪个Topic中也是能够定义的

与EMQX Kuiper进行集成,Kuiper反对从DeviceProfile中读取元数据

荡涤规定由KubeEdge下发给Kuiper

第三方利用间接从边缘MQTT中获取数据

状态监控

其实要做一个商用的产品,状态监控是十分重要的,其实我感觉KubeEdge目前在监控这块还是有些缺失,社区提供了一个叫Cloud Stream的通道,这个通道能够配合MetricServer,也能够配合Prometheus,然而须要配置iptables来将流量拦挡下来;还有一个是我如果一配就将整个流量拦挡下来了,所以这块是有些问题的。

所以咱们也做了另外一个计划:在边缘节点起了一个定时工作容器,这个定时工作做的事件也很简略,比方每5秒从我边缘的NodeExporter拉一次数据,把本地的数据拉完之后推到PushGateway上,PushGateway是普罗米修斯官网的一个组件,这个PushGateway是放在云上的,那通过这种形式咱们能够实现整个监控。

三、其余我的项目中遇到的一些问题

多租户共享

其实K8s自身是有多租户的设计的,但KubeEdge在做的时候咱们的Device没有思考Namespace的问题,所以咱们如果当初在Device中用Namespace是有bug的,所以当初KUbeEdge原身是没有方法把不同的设施放在不同的Namespace下,这个咱们只能从业务层的业务逻辑做封装,比方给Device打一些标签,通过标签去做筛选;边缘node工作节点也是没有方法归属Namespace的,然而在咱们的场景下,某个节点是属于某个租户的,是由这个租户独享的,这个时候咱们能够通过和下层业务逻辑进行封装。

IP地址限度

其实依照咱们当初的设计,咱们每个租户会给他们一个K8s集群,会去连它的一个边缘设施,这种的形式其实云端的集群要求有一个公网IP,IP资源其实还是比拟缓和的,怎么在地址无限的状况下比如说咱们做一个我的项目给你200个公网IP,但我可能有1000个用户,那怎么去解决?

1)IPv6是最彻底的解决方案:目前社区给的答案是反对,但咱们当初还没试过

2)端口复用:其实kubeEdge须要应用的端口比拟少,默认是10003,最多也就4-5个端口,其实一个公网IP是能够给多个kubeEdge实例去复用的

高可用计划:这个其实社区是有的,其实是复用了kubernetes自有的性能,Service+Deployment与状态查看 利用案例

案例一:OPC-UA数据采集与解决

通过咱们的放到了咱们的利用超市,用户订购了当前OPC-UA mapper下发到边缘的网关上,再通过咱们的一个页面配置就能够实现从

从边缘的工业设施下来采集数据,比如说:

  • OPC-UA mapper采集温度数据
  • 边缘节点告警利用间接从边缘获取数据
  • 超过阈值触发告警,暂停设施
  • KubeEdge对阈值进行调整

案例二:工业视频安防

这个是一个偏边缘自治的一个利用,其实和云目前的交互比拟少,它下发到边缘侧能够独立运行,次要在边缘侧做AI推理,那如果要它和云联合起来,咱们会把模型的训练放到云上,把训练实现的模型再通过KubeEdge推送到边缘,次要有:

KubeEdge治理边缘节点上的视频安防利用配置

边缘视频安防利用在边缘节点自治运行

摄像头中取流,AI推理

安全帽、工作服佩戴检测

危险区域禁入检测

四、总结

(1)基于KubeEdge工业数据采集

以后通过CustomizedProtocol与CustomizedValue,已能反对各类工业协定

通过ConfigMap能够实现云端对边缘数据利用(Mapper)的管制

旁路数据(Spec/Data)为时序数据的解决提供了更便捷的反对

(2)KubeEdge的产品化

多租户计划

多种监控计划

高可用计划

公网IP复用计划

本文分享自华为云社区《KubeEdge在国家工业互联网大数据中心的架构设计与利用》,原文作者:技术火炬手。

点击关注,第一工夫理解华为云陈腐技术~