[原创]边缘计算开源方案对比

通过分析对比EdgeX FoundryK3SKubeEdgeStarlingXOpenEdge五个开源边缘计算框架的差异,推荐选择华为开源的KubeEdge边缘计算集群方案来自建边缘计算集群。

一、五个边缘计算开源框架的简介:

1)EdgeX Foundry      Linux基金组织的开源项目。偏重于端侧设备的管理,定位是通用工业IOT边缘计算通用框架,提供了一些设备接入、边缘数据传输等场景的实现,但不具备云上对边缘端的应用和设备的管控、云边协同等智能边缘系统的能力,架构组件之间依赖复杂。
2)K3S                         Rancher Labs的开源产品。K3s是在边缘运行整个K8s集群的方案,不具备云边协同的能力;其次K3s虽然对K8s做了轻量化,但整体资源要求仍然较高,无法运行在IOT Hub、工业网关等小型设备中。
3)KubeEdge              华为开源产品,打通了云、边、端的整体流程:
        · 用户能够在云上统一管理边缘节点上的应用、设备
       · 提供了云边协同的能力,能够同步云边的应用、设备的数据
       · 针对复杂多样的边缘设备,KubeEdge定义了一套通用的设备管理API(K8s CRD)以及设备协议解耦层,用户可以方便地使用KubeEdge在云上管理各种边缘设备
       · 针对云边网络不稳定的情况,提供了云边数据协同的可靠性传输、边缘元数据持久化
       · 针对边缘资源不足的情况,轻量化裁剪了Kubelet,支持在256MB的小型设备上运行
4)StarlingX               Intel和WindRiver开源的边缘计算项目。StarlingX是一个软件栈,他包含了打包,编译,安装配置,openstack本身,WindRiver的MTCE平台,以及WindRiver针对电信云开发的VIM等等。基于OpenStack的大规模边缘计算方案,集成了OpenStack的核心服务用于实现计算,网络,存储等能力。目标是实现边缘端的无人值守,虚拟机级别的管理。边缘端组成边缘云互相协同,以及和中心云实现协同。
5)OpenEdge            百度开源的面向端的工业互联网智能边缘计算方案,需要和百度的云端管理套件BIE结合实现云边协同。

 

二、架构对比:

1)EdgeX Foundry

EdgeX总架构图.png

2)K3S

3)KubeEdge

4)StarlingX

5)OpenEdge

 

三、功能对比:

 

EdgeX Foundry

K3S

KubeEdge

StarlingX

OpenEdge

云边协同 不支持 不支持 支持 支持 支持
原生支持K8S 不支持 支持 支持 不支持 不支持
边缘组件资源占用 最小(内存256M) 较大 较大
部署复杂度 复杂 简单 简单 复杂 复杂
是否去中心化

是否支持MQTT 支持 支持 支持 支持 支持
容器化编排 不支持 支持 支持 支持 不支持

 

通过以上对各个边缘计算开源方案的对比,结合我们的业务场景和已有的技术栈(基于K8S平台),KubeEdge和K3S是比较合适我们业务的边缘计算集群产品。其中KubeEdge的云边端协同,支持的功能和性能整体比K3S更加出色。所以推荐使用KubeEdge产品作为我们边缘计算集群的落地实施对象。下面将详细介绍一下KubeEdge目前稳定版本(v1.1.0版本,v1.2.0版本将在2019年12月底发布)支持的特性和功能:

1.关于部署:

kubeEdge 包括 cloud 和 edge 部分,在 kubernetes 构建,在 cloud 与  edge 端提供核心的基础支持,比如网络,应用,部署以及元数据的同步等。
安装kubeEdge 需要安装 kubernetes 集群,cloud 与 edge 部分
cloud side: docker, kubernetes cluster and cloudcore.
edge side:docker, mqtt and edgecore.

2.kubeedge 组件:

Edged:一个运行在 edge 节点的 agent 程序,管理边缘的容器化应用程序

EdgeHub:边缘的通信接口模块。这是一个 Web 套接字客户端,负责边缘计算与云服务的交互。包括同步云端资源到边缘端,以及报告边缘端 host 和 device 状态到云端

CloudHub:云端通讯接口模块。一个 Web 套接字服务器,负责监视云端的更改、缓存以及向EdgeHub 发送消息

EdgeController:管理边缘节点。它是一个扩展的 Kubernetes 控制器,管理边缘节点和 pod 元数据,以便数据可以面向特定的边缘节点

EventBus:使用 MQTT 处理内部边缘通信。MQTT 客户端与 MQTT 服务器(mosquitto)交互,为其他组件提供发布和订阅功能

DeviceTwin:处理设备元数据的设备软件镜像。该模块有助于处理设备状态并将其同步到云上。它还为应用程序提供查询接口,它连接到一个轻量级数据库(SQLite)

MetaManager:管理边缘节点上的元数据。这是 Edged 和 Edgehub 之间的消息处理器。负责在轻量级数据库(SQLite)中存储 / 检索元数据

3.支持的特性:

• Replace data exchange format between cloud and edge from json to protobuf.

• Support reliable message delivery from cloud to edge.
• Evaluate gRPC for cloud to edge communication.
• Support CSI for persistent storage (using PV/PVC/StorageClass) at edge.

• Support ingress at edge.
• Add admission-webhook based validation for device CRDs.
• Enhance performance and reliability of KubeEdge infrastructure.
• Upgrade Kubernetes dependencies in vendor to v1.15.
• Migrate to Go module for dependency management.
• Improve contributor experience by defining project governance policies, release process, membership rules etc.

• Improve the performance and e2e tests with more metrics and scenarios.

4.未来版本将支持的特性:

• Support edge-cloud communication using edgemesh.

• Add Layer 4 proxy support in edgemesh.

• Istio-based service mesh across Edge and Cloud where micro-services can communicate freely in the mesh.

• Enable function as a service at the Edge.
• Support more types of device protocols such as OPC-UA, Zigbee.
• Evaluate and enable much larger scale Edge clusters with thousands of Edge nodes and millions of devices.

• Enable intelligent scheduling of applications to large scale Edge clusters.

• Data management with support for ingestion of telemetry data and analytics at the edge.

• Security at the edge.
• Support for monitoring at the edge.

5.功能原理介绍:

1)KubeEdge的云边协同通信测试过包括Grpc、WebSocket、Quic,最后发现WebSocket是性能最好的,所以默认采用了WebSocket。Quic作为备选项,在网络频繁断开等很不稳定场景有优势。KubeEdge云边消息传递是通过EdgeHub跟CloudHub间的Websocket或Quic协议的长连接传递的。

2)KubeEdge会将边缘收到的应用、设备元数据都进行本地持久化。相比Kubelet在内存中缓存对象的方式,可以有效保证节点离线、故障恢复时的业务自治和快速自愈。

3)edgemesh组件实现边缘节点之间的pod通信和边缘pod到云端pod的通信,但是目前还不支持云端pod到边缘侧pod的通信。

6.尝鲜结果:

通过kubeedge源码自带的一键部署脚本部署kubeedge集群,并熟悉组件的配置,得知在已有K8S集群平台上部署集成KubeEdge比较容易,阻碍不会很大。目前体验了在云端编排部署容器后,在边缘侧离线自治和故障自愈的功能。通过停止cloudcore和edgecore组件来模拟断开云边的连接和边缘节点故障重启,容器在断开和云端的连接后仍然正常运行,在节点重启后能自动拉起容器运行正常。目前发现大部分功能和阿里云的边缘集群差不多,可以考虑取代阿里云的边缘集群实现自建边缘计算集群。

另外:K3S是轻量化的K8S集群,在边缘侧部署一个完成的集群,完全的在边缘侧实现编排管理。如果不考虑云边协同的场景也可以使用,如:海外场景。不过KubeEdge的EdgeSite组件也是侧重于边缘侧的编排管理而生的,也具备这样的能力,只是目前版本还不成熟和完善。

 

其他功能在测试中。。。

 

posted @ 2019-12-26 19:34  wsjhk  阅读(10539)  评论(1编辑  收藏  举报