[原创]边缘计算开源方案对比
通过分析对比EdgeX Foundry、K3S、KubeEdge、StarlingX和OpenEdge五个开源边缘计算框架的差异,推荐选择华为开源的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
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组件也是侧重于边缘侧的编排管理而生的,也具备这样的能力,只是目前版本还不成熟和完善。
其他功能在测试中。。。