五个边缘计算开源框架功能对比

五个边缘计算开源框架的简介：

EdgeX Foundry

Linux基金组织的开源项目。

github 开源地址

偏重于端侧设备的管理，定位是通用工业IOT边缘计算通用框架，提供了一些设备接入、边缘数据传输等场景的实现，但不具备云上对边缘端的应用和设备的管控、云边协同等智能边缘系统的能力，架构组件之间依赖复杂。

K3s

Rancher Labs的开源产品。

github 开源地址

K3s是在边缘运行整个K8s集群的方案，不具备云边协同的能力；其次K3s虽然对K8s做了轻量化，但整体资源要求仍然较高，无法运行在IOT Hub、工业网关等小型设备中。

K3S是CNCF官方认证的Kubernetes发行版，开源时间较KubeEdge稍晚。K3S专为在资源有限的环境中运行Kubernetes的研发和运维人员设计，目的是为了在x86、ARM64和ARMv7D架构的边缘节点上运行小型的Kubernetes集群。

事实上，K3S就是基于一个特定版本Kubernetes（例如：1.13）直接做了代码修改。K3S分Server和Agent，Server就是Kubernetes管理面组件 + SQLite和Tunnel Proxy，Agent即Kubernetes的数据面 + Tunnel Proxy。

为了减少运行Kubernetes所需的资源，K3S对原生Kubernetes代码做了以下几个方面的修改：

删除旧的、非必须的代码。K3S不包括任何非默认的、Alpha或者过时的Kubernetes功能。除此之外，K3S还删除了所有非默认的Admission Controller，in-tree的cloud provider和存储插件；

整合打包进程。为了节省内存，K3S将原本以多进程方式运行的Kubernetes管理面和数据面的多个进程分别合并成一个来运行；

使用containderd替换Docker，显著减少运行时占用空间；

引入SQLite代替etcd作为管理面数据存储，并用SQLite实现了list/watch接口，即Tunnel Proxy；

加了一个简单的安装程序。

K3S的所有组件（包括Server和Agent）都运行在边缘，因此不涉及云边协同。如果K3S要落到生产，在K3S之上应该还有一个集群管理方案负责跨集群的应用管理、监控、告警、日志、安全和策略等，遗憾的是Rancher尚未开源这部分能力。

KubeEdge

华为开源产品

github 开源地址

打通了云、边、端的整体流程： · 用户能够在云上统一管理边缘节点上的应用、设备 · 提供了云边协同的能力，能够同步云边的应用、设备的数据 · 针对复杂多样的边缘设备，KubeEdge定义了一套通用的设备管理API（K8s CRD）以及设备协议解耦层，用户可以方便地使用KubeEdge在云上管理各种边缘设备 · 针对云边网络不稳定的情况，提供了云边数据协同的可靠性传输、边缘元数据持久化 · 针对边缘资源不足的情况，轻量化裁剪了Kubelet，支持在256MB的小型设备上运行

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 组件：

KubeEdge的边缘进程包含以下5个组件：

edged是个重新开发的轻量化Kubelet，实现Pod，Volume，Node等Kubernetes资源对象的生命周期管理；

metamanager负责本地元数据的持久化，是边缘节点自治能力的关键；

edgehub是多路复用的消息通道，提供可靠和高效的云边信息同步；

devicetwin用于抽象物理设备并在云端生成一个设备状态的映射；

eventbus订阅来自于MQTT Broker的设备数据。

KubeEdge的云端进程包含以下2个组件：

cloudhub部署在云端，接收edgehub同步到云端的信息；

edgecontroller部署在云端，用于控制Kubernetes API Server与边缘的节点、应用和配置的状态同步。

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的通信。

StarlingX

Intel和WindRiver开源的边缘计算项目

github 开源地址

StarlingX是一个软件栈，他包含了打包，编译，安装配置，openstack本身，WindRiver的MTCE平台，以及WindRiver针对电信云开发的VIM等等。基于OpenStack的大规模边缘计算方案，集成了OpenStack的核心服务用于实现计算，网络，存储等能力。目标是实现边缘端的无人值守，虚拟机级别的管理。边缘端组成边缘云互相协同，以及和中心云实现协同。

Baetyl

百度开源的面向端的工业互联网智能边缘计算方案

github 开源地址

它需要和百度的云端管理套件BIE结合实现云边协同

KubeEdge与K3S全方位对比

部署模型

KubeEdge遵循的是以下部署模型:

KubeEdge是一种完全去中心化的部署模式，管理面部署在云端，边缘节点无需太多资源就能运行Kubernetes的agent，云边通过消息协同。从Kubernetes的角度看，边缘节点 + 云端才是一个完整的Kubernetes集群。这种部署模型能够同时满足“设备边缘”和“基础设施边缘”场景的部署要求。

K3S的部署模型如下所示：

K3S会在边缘运行完整的Kubernetes集群，这意味着K3S并不是一个去中心化的部署模型，每个边缘都需要额外部署Kubernetes管理面。这种部署模型带来的问题有：

在边缘安装Kubernetes管理面将消耗较多资源，因此该部署模型只适合资源充足的“基础设施边缘”场景，并不适用于资源较少的“设备边缘”的场景；

集群之间网络需要打通；

为了管理边缘Kubernetes集群还需要在上面叠加一层多集群管理组件（遗憾的是该组件未开源）。

云边协同

云边协同是KubeEdge的一大亮点。KubeEdge通过Kubernetes标准API在云端管理边缘节点、设备和工作负载的增删改查。边缘节点的系统升级和应用程序更新都可以直接从云端下发，提升边缘的运维效率。另外，KubeEdge底层优化的多路复用消息通道相对于Kubernetes基于HTTP长连接的list/watch机制扩展性更好，允许海量边缘节点和设备的接入。KubeEdge云端组件完全开源，用户可以在任何公有云/私有云上部署KubeEdge而不用担心厂商锁定，并且自由集成公有云的其他服务。

K3S并不提供云边协同的能力。

边缘节点离线自治

与Kubernetes集群的节点不同，边缘节点需要在完全断开连接的模式下自主工作，并不会定期进行状态同步，只有在重连时才会与控制面通信。此模式与Kubernetes管理面和工作节点通过心跳和list/watch保持状态更新的原始设计非常不同。

KubeEdge通过消息总线和元数据本地存储实现了节点的离线自治。用户期望的控制面配置和设备实时状态更新都通过消息同步到本地存储，这样节点在离线情况下即使重启也不会丢失管理元数据，并保持对本节点设备和应用的管理能力。

K3S也不涉及这方面能力。

设备管理

KubeEdge提供了可插拔式的设备统一管理框架，允许用户在此框架上根据不同的协议或实际需求开发设备接入驱动。当前已经支持和计划支持的协议有：MQTT，BlueTooth，OPC UA，Modbus等，随着越来越多社区合作伙伴的加入，KubeEdge未来会支持更多的设备通信协议。KubeEdge通过device twins/digital twins实现设备状态的更新和同步，并在云端提供Kubernetes的扩展API抽象设备对象，用户可以在云端使用kubectl操作Kubernetes资源对象的方式管理边缘设备。

K3S并不涉及这方面能力。

轻量化

为了将Kubernetes部署在边缘，KubeEdge和K3S都进行了轻量化的改造。区别在于K3S的方向是基于社区版Kubernetes不断做减法（包括管理面和控制面），而KubeEdge则是保留了Kubernetes管理面，重新开发了节点agent。

需要注意的是，K3S在裁剪Kubernetes的过程中导致部分管理面能力的缺失，例如：一些Admission Controller。而KubeEdge则完整地保留了Kubernetes管理面，没有修改过一行代码。

下面我们将从二进制大小、内存和CPU三个维度对比KubeEdge和K3S的资源消耗情况。由于KubeEdge的管理面部署在云端，用户不太关心云端资源的消耗，而K3S的server和agent均运行在边缘，因此下面将对比KubeEdge agent，K3S agent和K3S server这三个不同的进程的CPU和内存的资源消耗。

测试机规格为4 vCPU，8GB RAM。

内存消耗对比

分别用KubeEdge和K3S部署0~100个应用，分别观测两者的内存消耗，对比如下所示：

从上图可以看出，内存消耗：KubeEdge agent \u0026lt; K3S agent \u0026lt; K3S Server。有意思的是，K3S agent即使不运行应用也消耗100+MB的内存，而K3S server在空跑的情况下内存消耗也在300MB左右。

CPU使用对比

分别用KubeEdge和K3S部署0~100个应用，分别观测两者的CPU使用情况，对比如下所示：

从上图可以看出，KubeEdge agent CPU消耗要比K3S agent和server都要少。

二进制大小

KubeEdge agent二进制大小为62MB，K3S二进制大小为36MB。

大规模

Kubernetes原生的可扩展性受制于list/watch的长连接消耗，生产环境能够稳定支持的节点规模是1000左右。KubeEdge作为华为云智能边缘服务IEF的内核，通过多路复用的消息通道优化了云边的通信的性能，压测发现可以轻松支持5000+节点。

而K3S的集群管理技术尚未开源，因为无法得知K3S管理大规模集群的能力。

小结

K3S最让人印象深刻的创新在于其对Kubernetes小型化做的尝试，通过剪裁了Kubernetes一些不常用功能并且合并多个组件到一个进程运行的方式，使得一些资源较充足的边缘节点上能够运行Kubernetes，让边缘场景下的用户也能获得一致的Kubernetes体验。然而通过上面的性能对比数据发现，K3S的资源消耗还是比KubeEdge要高出好几倍，而且动辄几百MB的内存也不是大多数设备边缘节点所能提供的。最重要的是，Kubernetes最初是为云数据中心而设计的，很多边缘计算场景特殊的问题原生Kubernetes无法很好地解决， K3S直接修改Kubernetes的代码甚至基础实现机制（例如，使用SQLite替换etcd）的做法仍值得商榷。关于什么能改，什么不能改以及怎么改？每个用户根据自己的实际需求有各自的观点，而且也很难达成一致。另外， K3S这种侵入式的修改能否持续跟进Kubernetes上游的发展也是一个未知数。

KubeEdge和K3S走的是另一条道路，KubeEdge是一个从云到边缘再到设备的完整边缘云平台，它与Kubernetes的耦合仅仅是100%兼容Kubernetes原生API。KubeEdge提供了K3S所不具备的云边协同能力，开发了更轻量的边缘容器管理agent，解决了原生Kubernetes在边缘场景下的离线自治问题，并且支持海量异构边缘设备的接入等。KubeEdge最近捐献给CNCF，成为CNCF边缘计算领域的第一个正式项目，就是为了和社区合作伙伴一起制定云和边缘计算协同的标准，结束边缘计算没有统一标准和参考架构的混沌状态，共同推动边缘计算的产业发展。

参考资料

1. 边缘计算开源方案对比

2. KubeEdge向左，K3S向右