| 编辑推荐: |
本文主要是介绍云原生与边缘计算的结合并对KubeEdge架构上两部分云端和边缘侧进行详细阐述，希望对您有所帮助
。
本文来自于科技媒体DoNews，由火龙果软件Alice编辑、推荐。 |
|
云原生与边缘计算的完美结合
经过我们调研发现,传统的嵌入式设备开发面临着诸多挑战,严重制约着边缘设备上云以及大规模设备在云化场景下开发效率。
(1) 边云生态的割裂,物理设备访问难度高,与IT技术割裂,开发难度高产品上市周期长
(2) 日趋复杂的边缘业务的部署,对高度分布和大规模可扩展性缺乏考虑
(3) 缺少和云的协同以及边缘和边缘的协同,构建分布式系统难度高
(4) OT和IT世界技术割裂,协同门槛高
那么,云原生和边缘计算相遇,会擦出什么样激烈的“火花”?现在大多数的边缘设备都与云端配合使用,比如工程师们可以在云端训练机器学习模型,训练好之后将推理模型应用于边缘节点。无论从边缘应用的分发,边缘应用的可靠性还是边云协同的机制上,云原生边缘计算有利于让边缘也具备像云一样的“弹性”,让应用可以“顺滑”的部署到边缘,保持应用在边缘与云端的一致性。
KubeEdge通过更优的架构和技术实现,能完美应对当前遇到的挑战,帮助工程师从底层技术设施的管理中解放出来,将注意力集中到更高抽象层次的应用开发之中。这样,“云-边-端”就像是一个完美的整体,最终用户无需感知边缘设备的复杂分布。
· 通过将AI能力、大数据能力等延伸到边缘,解决与云上服务的数据协同、任务协同、管理协同、安全协同诉求
· 通过数据本地化处理、边缘节点离线自治,解决了云和边缘之间的网络可靠性和带宽限制的问题
· 通过大幅优化边缘组件的资源占用(二进制大小约46MB,运行时内存占用约10MB),解决了边缘资源的约束问题
· 通过在云边之间构建的双向多路复用网络通道,解决了从云端管理高度分布的海量节点和设备难的问题
· 南向支持对接物联网主流的通信协议(MQTT,Bluetooth,Zigbee,BACnet等),解决了异构硬件接入难的问题
综合起来看,传统的嵌入式本地计算和云原生边缘计算的差异可以归纳如下:
KubeEdge架构
KubeEdge即Kube+Edge,顾名思义就是依托K8S的容器编排和调度能力,实现云边协同、计算下沉、海量设备的平滑接入。KubeEdge架构上包含两部分,分别是云端和边缘侧。云端负责应用和配置的下发,边缘侧则负责运行边缘应用和管理接入设备。
Edged:管理边缘的容器化应用程序。
EdgeHub:边缘的通信接口模块。这是一个 Web 套接字客户端,负责边缘计算与云服务的交互。
CloudHub:云端通讯接口模块。一个 Web 套接字服务器,负责监视云端的更改、缓存以及向 EdgeHub
发送消息。
EdgeController:管理边缘节点。它是一个扩展的 Kubernetes 控制器,管理边缘节点和
pod 元数据,以便数据可以面向特定的边缘节点。
EventBus:使用 MQTT 处理内部边缘通信。它是一个 MQTT 客户机,可以与 MQTT
服务器(mosquitto)交互,为其他组件提供发布和订阅功能。
DeviceTwin:它是处理设备元数据的设备软件镜像。该模块有助于处理设备状态并将其同步到云上。它还为应用程序提供查询接口,因为它连接到一个轻量级数据库(SQLite)。
MetaManager:它管理边缘节点上的元数据。这是 Edged 和 Edgehub 之间的消息处理器。它还负责在轻量级数据库(SQLite)中存储
/ 检索元数据。
极致优化
容器天然的轻量化和可移植性,非常适合边缘计算的场景,鉴于K8S已经成为云原生编排的事实标准,因此携手K8S进入边缘将很有可能结束边缘计算当前混沌的状态,并定义云端和边缘统一的应用部署和管理的标准。
然而,由于边缘场景通信的不稳定性和严苛的资源消耗限制,导致原生的K8S组件无法直接运行在边缘节点上,例如:工业网关等。而受限于K8S本身list/watch机制带来的disconnect问题,数据面和管理面断连后,无法做到本地自治。
KubeEdge选择的是“轻边缘”架构,即边缘侧的容器引擎和设备管理agent尽量轻量化,管理面运行在云端,且构建在K8S的调度能力之上,100%兼容K8S原生API。KubeEdge
all in K8S的设计理念使得用户可以围绕K8S的标准API定制需求或者轻松集成云原生生态中的成熟项目。
从ServiceMesh到EdgeMesh
在过去的一年中,服务网格(Service Mesh)已经演变成为云原生堆栈的重要组成部分。像 Paypal,Lyft,Ticketmaster
和 CreditKarma 这样的高流量公司都已经为其生产应用添加了 ServiceMesh。ServiceMesh与云原生应用的兴起有关。在云原生模型中,单个应用程序可能包含数百个服务,每个服务可能有数千个实例,并且这些实例中的每一个都可能处于不断变化的状态,合理管理使用
ServiceMesh,对于确保端到端的性能和可靠性至关重要。
随着信通院《云计算与边缘计算协同九大应用场景(2019年)》的发布,“云边协同是边缘计算发展的重要驱动力和不可分割的需求”已经逐渐成为业界共识。当纯粹的计算在边缘转向云边协同,如何以云原生的方式构建一个跨越了边缘和云端的分布式系统就成为了一个至关重要的问题:
(1)边缘应用需要有完善的微服务治理能力,以满足日趋复杂的边缘业务模型;
(2)边云、边边的协同成为边缘应用的基本要求,以满足海量边缘数据的处理。
使用EdgeMesh可以支持跨越边界的微服务访问,EdgeMesh特性基于标准的istio进行服务治理控制,引入EdgeMesh-proxy负责边缘侧流量转发以及P2P技术跨子网通信,提供云-边、边-边通信,最终实现跨越边云的一致的服务发现和访问体验。
a)边边协同
b) 边云协同
边缘设备管理:设备访问微服务化
Kubernetes提供的设备插件(device plugin)框架, 旨在通过Kubelet管理“绑定”在节点上的硬件(加速器),例如:GPU、FPGAs、InfiniBand等,为Pod中的容器应用提供更强的计算和网络性能。
而KubeEdge的设备管理关注的是与边缘通信的外部设备,例如:蓝牙终端、智能传感器、工业设备等。KubeEdge对设备管理的实现采用的是Kubernetes官方推荐的Operator方式,并实现了设备孪生(device
twin)。设备管理Operator的核心是Device CRD和Device Controller,其中Device
CRD用来描述设备的状态等元数据,Device Controller运行在云上,负责在云和边之间同步设备状态的更新(包括设备实际状态和用户设定的期望状态)。
KubeEdge设备管理的工作流程如下图所示:
Device Controller会把用户设定的设备孪生期望状态和配置下发到边缘,而在边缘的组件则要接收并处理这些信息。为了避免edge_core引入量处理边缘设备通信的代码,同时保持整个项目良好的易定制性,KubeEdge设计了一个边缘设备驱动统一管理引擎Mapper。
Mapper之于KubeEdge的作用如同CRI之于Kubernetes,只是CRI作为Kubernetes定义的容器接口与底层容器引擎打交道,而Mapper作为一个开放接口方便不同的设备协议接入KubeEdge这个边缘计算平台。
KubeEdge v1.0中内置支持的设备协议是蓝牙,后续版本将逐步增加对OPC-UA和Modbus的支持。有了Mapper的解耦层,用户可以方便地根据实际需要开发自己的Mapper来实现与特定设备的通信,同时社区也欢迎广大开发者贡献更多的协议实现。
Mapper的架构如下图所示:
|
