通过分析对比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组件也是侧重于边缘侧的编排管理而生的，也具备这样的能力，只是目前版本还不成熟和完善。
其他功能在测试中。。。