共计 4075 个字符，预计需要花费 11 分钟才能阅读完成。
【摘要】在 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 在国家工业互联网大数据中心的架构设计与利用》，原文作者：技术火炬手。
点击关注，第一工夫理解华为云陈腐技术~
