边缘计算云原生开源方案选型比较

随着 Kubernetes 已经成为容器编排和调度的事实标准，各大公有云厂商都已经基于 Kubernetes 提供了完善的 Kubernetes 云上托管服务。同时也看到越来越多的企业、行业开始在生产中使用 Kubernetes, 拥抱云原生。在各行各业数字化转型和上云过程中，公有云厂商也在主动拥抱传统线下环境，在思考各种各样的解决方案使云上能力向边缘(或线下)延伸。而 Kubernetes 由于屏蔽了底层架构的差异性，可以帮助应用平滑地运行在不同的基础设施上的特性，云上的 Kubernetes 服务也在考虑拓展其服务边界，云原生和边缘计算结合的想法自然就呼之欲出了。

目前国内各个公有云厂商也都开源了各自基于 Kubernetes 的边缘计算云原生项目。如华为云的 KubeEdge，阿里云的 OpenYurt，腾讯云的 SuperEdge。目前网上很少有从技术视角来介绍这几个项目优缺点的文章，本文试着从技术视角，从开源视角来分析这几个项目，希望可以给大家做项目选型时提供一些借鉴。

1. 比较思路

这几个项目都是云边一体，云边协同的架构，走的是 Kubernetes 和边缘计算结合的路数，因此决定从以下几点比较:

（1） 各个项目的开源状况：比如开源项目的背景、开源的时间、是否进入了 CNCF 等；

（2）Kubernetes 架构:

• 先对比与 Kubernetees 的架构差异：主要关注是否修改 Kubernetes，和；Kubernetes 一键式转换等

• 根据架构差异对比和 Kubernetes 的能力增强点；主要关注边缘自治，边缘单元化，轻量化等能力

• 最后看一下架构差异可能带来的影响: 主要关注运维监控能力，云原生生态兼容性，系统稳定性等方面

（3）对边缘计算场景支持能力:

• 主要关注是否具备端设备的管理能力

接下来以项目的开源顺序，从上述几个方面来介绍各个项目。

2.边缘云原生开源项目对比

2.1 KubeEdge

（1）开源状况

KubeEdge 是华为云于 2018 年 11 月份开源的，目前是 CNCF 孵化项目。其架构如下:

（2）与 Kubernetes 的架构差异

首先从架构图可以看到，云端(k8s master)增加了 Cloud Hub 组件和各类 controller，而在边缘端(k8s worker)没有看到原生的 kubelet 和 kube-proxy，而是一个对原生组件进行重写了 EdgeCore 组件。

从架构图看 EdgeCore 是基于 kubelet 重构的，为了保证轻量化，裁剪了原生 kubelet 的部分能力，同时也增加了很多适配边缘场景的能力。具体如下:

• Cloud Hub+EdgeHub 模块: 抛弃了原生 kubernetes 的组件间数据同步 list/watch 机制，改成基于 websocket/quic 协议从云端往边缘推送模式。

• 节点元数据缓存模块(MetaManager): 把节点维度的数据持久化在本机的 SQLite 数据库中，当云边网络不稳定时 Edged 模块将从本地数据库中获取数据用于业务的生命周期管控。

• DeviceController+设备管理模块(DeviceTwin): 把设备管理能力直接集成到 EdgeCore 中，为用户提供原生的设备管理能力。

上述的架构设计，对比 Kubernetes 的能力增强点主要有：

• 边缘自治：通过增加节点元数据缓存，可以规避云边断网状态下，边缘业务或者节点重启时，边缘组件可以利用本地缓存数据进行业务恢复，这就带来了边缘自治的好处。

• 轻量化: 削减了部分 kubelet 功能(如 CSI，CNI 等)，从而使边缘 EdgeCore 组件相比原生 kubelet 组件更加轻量。同时因为节点上增加了 SQLite 数据库，所以节点维度相比原生节点是否轻量待确认，欢迎熟悉的同学提供数据。

架构差异可能带来的影响：

• 云原生生态兼容性不足：

1. 跟随社区同步演进挑战大: 由于对 Kubernetes 系统的侵入式修改，后续跟随 Kubernetes 社区的演进将会遇到很大挑战。

2. 边缘节点无法运行 Operator：因为云边通信机制的修改，Cloud Hub 只能往边缘推送有限的几种资源(如 Pod，ConfigMap 等)。而 Operator 既需要自定义 CRD 资源，又需要 list/watch 云端获取关联资源，因此社区的 Operator 无法运行的 KubeEdge 的边缘节点上。

3. 边缘节点不适合运行需要 list/watch 云端的应用: 因为云边通信机制的修改，导致原来需要使用 list/watch 机制访问 kube-apiserver 的应用，都无法通过 hub tunnel 通道访问 kube-apiserver，导致云原生的能力在边缘侧大打折扣。

• 运维监控能力支持有限：因为目前云边通信链路是 kube-apiserver --> controller --> Cloud Hub -->EdgeHub -->MetaManager 等，而原生 Kubernetes 运维操作(如 kubectl proxy/logs/exec/port-forward/attch 等)是 kube-apiserver 直接请求 kubelet。目前 KubeEdge 社区最新版本也仅支持 kubectl logs/exec/metric，其他运维操作目前还不支持。

• 系统稳定性提升待确定:

1. 基于增量数据的云边推送模式：可以解决边缘 watch 失败时的重新全量 list 从而引发的 kube-apiserver 压力问题，相比原生 Kubernetes 架构可以提升系统稳定性。

2. Infra 管控数据和业务管控数据耦合：Kubernetes 集群的管控数据(如 Pod，ConfigMap 数据)和边缘业务数据(设备管控数据)使用同一条 websocket 链路，如果边缘管理大量设备或者设备更新频率过高，大量的业务数据将可能影响到集群的正常管控，从而可能降低系统的稳定性。

边缘计算场景支持能力

• 设备管理能力: 这个能力直接集成在 edged 中，给 iot 用户提供了一定的原生设备管理能力。

2.2OpenYurt

（1）开源状况

OpenYurt 是阿里云于 2020 年 5 月份开源的，目前是 CNCF 沙箱项目。架构如下:

（2）与 Kubernetes 的架构差异

OpenYurt 的架构设计比较简洁，采用的是无侵入式对 Kubernetes 进行增强。在云端(K8s Master)上增加 Yurt Controller Manager, Yurt App Manager 以及 Tunnel Server 组件。而在边缘端(K8s Worker)上增加了 YurtHub 和 Tunnel Agent 组件。从架构上看主要增加了如下能力来适配边缘场景：

• YurtHub: 代理各个边缘组件到 K8s Master 的通信请求，同时把请求返回的元数据持久化在节点磁盘。当云边网络不稳定时，则利用本地磁盘数据来用于边缘业务的生命周期管控。同时云端的 Yurt Controller Manager 会管控边缘业务 Pod 的驱逐策略。

• Tunnel Server/Tunnel Agent: 每个边缘节点上的 Tunnel Agent 将主动与云端 Tunnel Server 建立双向认证的加密的 gRPC 连接，同时云端将通过此连接访问到边缘节点及其资源。

• Yurt App Manager：引入的两个 CRD 资源: NodePool 和 UnitedDeployment. 前者为位于同一区域的节点提供批量管理方法。 后者定义了一种新的边缘应用模型以节点池维度来管理工作负载。

上述的架构设计，对比 Kubernetes 的能力增强点主要有：

• 边缘单元化：通过 Yurt App Manager 组件，从单元化的视角，管理分散在不同地域的边缘资源，并对各地域单元内的业务提供独立的生命周期管理，升级，扩缩容，流量闭环等能力。且业务无需进行任何适配或改造。

• 边缘自治: 因为每个边缘节点增加了具备缓存能力的透明代理 YurtHub，从而可以保障云边网络断开，如果节点或者业务重启时，可以利用本地缓存数据恢复业务。

• 云边协同(运维监控)： 通过 Tunnel Server/Tunnel Agent 的配合，为位于防火墙内部的边缘节点提供安全的云边双向认证的加密通道，即使边到云网络单向连通的边缘计算场景下，用户仍可运行原生 kubernetes 运维命令(如 kubectl proxy/logs/exec/port-forward/attach 等)。同时中心式的运维监控系统(如 prometheus, metrics-server 等)也可以通过云边通道获取到边缘的监控数据。

• 云原生生态兼容:

1. 所有功能均是通过 Addon 或者 controller 形式来增强 Kubernetes，因此保证来对 Kubernetes 以及云原生社区生态的 100%兼容。

2. 另外值得一提的是：OpenYurt 项目还提供了一个 YurtCtl 工具，可以用于原生 Kubernetes 和 OpenYurt 集群的一键式转换，

架构差异可能带来的影响

• 原生 Kubernetes 带来的系统稳定性挑战：因为 OpenYurt 没有修改 Kubernetes，所以这个问题也是原生 Kubernetes 在边缘场景下的问题。当云边长时间断网再次恢复时，边缘到云端会产生大量的全量 List 请求，从而对 kube-apiserver 造成比较大的压力。边缘节点过多时，将会给系统稳定性带来不小的挑战。

• 边缘无轻量化解决方案: 虽然 OpenYurt 没有修改 Kubernets，但是在边缘节点上增加 YurtHub 和 Tunnel Agent 组件。目前在最小的 1C1G 的系统上运行成功，更小规格机器待验证。

边缘计算场景

• 无设备管理能力：OpenYurt 目前没有提供设备管理的相关能力，需要用户以 workload 形式来运行自己的设备管理解决方案。虽然不算是架构设计的缺点，但是也算是一个边缘场景的不足点。

2.3.SuperEdge

（1）开源状况

SuperEdge 是腾讯云于 2020 年 12 月底开源的，目前还是开源初期阶段。其架构如下：

（2）与 Kubernetes 的架构差异

SuperEdge 的架构设计比较简洁，也是采用的无侵入式对 Kubernetes 进行增强。在云端(K8s Master)上增加 Application-Grid Controller, Edge-Health Admission 以及 Tunnel Cloud 组件。而在边缘端(K8s Worker)上增加了 Lite-Apiserver 和 Tunnel Edge，Application-Grid Wrapper 组件。从架构上看主要增加了如下能力来适配边缘场景：

• Lite-Apiserver: 代理各个边缘组件到 K8s Master 的通信请求，同时把请求返回的元数据持久化在节点磁盘。当云边网络不稳定时，则利用本地磁盘数据来用于边缘业务的生命周期管控。同时基于边缘 Edge-Health 上报信息，云端的 Edge-Health Admission 会管控边缘业务 Pod 的驱逐策略。

• Tunnel Cloud/Tunnel Edge: 每个边缘节点上的 Tunnel Edge 将主动与云端 Tunnel Cloud 建立双向认证的加密的 gRPC 连接，同时云端将通过此连接访问到边缘节点及其资源。

• Application-Grid Controller：引入的两个 CRD 资源: ServiceGrids 和 DeploymentGrids. 前者为位于同一区域的业务流量提供闭环管理。 后者定义了一种新的边缘应用模型以节点池为单位来管理工作负载。

与 OpenYurt 对比

• 从 SuperEdge 的架构以及功能分析下来，发现 SuperEdge 从架构到功能和 OpenYurt 基本一致。这也从侧面印证，边缘计算云原生这个领域，各大厂商都在如火如荼的投入。

• SuperEdge 与 Kubernetes 的对比分析可以参照 OpenYurt 的分析，这里我们从代码角度分析 SuperEdge 和 OpenYurt 的差异：

• YurtHub 和 Lite-Apiserver: YurtHub 采取了完善的证书管理机制和本地数据缓存设计，而 Lite-Apiserver 使用的是节点 kubelet 证书和数据简单缓存。

• Tunnel 组件：OpenYurt 的 Tunnel 组件是基于 Kubernetes 社区的开源项目 ANP(https://github.com/kubernetes-sigs/apiserver-network-proxy)，同时实现了完善的证书管理机制。而 SuperEdge 的 Tunnel 组件同样也是使用节点证书，同时请求转发是基于自行封装的 gRPC 连接。OpenYurt 底层的 ANP 相比原生 gRPC，会更好适配 kube-apiserver 的演进。

• 单元化管理组件: OpenYurt 单元化管理支持 Deployment 和 StatefulSet,而 SuperEdge 的单元化管理只支持 Deployment。另外 OpenYurt 的 NodePool 和 UnitedDeployment 的 API 定义是标准云原生的设计思路，而 SuperEdge 的 ServiceGrids 和 DeploymentGrids 的 API 定义显得随意一些。

• 边缘状态检测，这个能力 OpenYurt 未实现，SuperEdge 的设计需要 kubelet 监听节点地址用于节点间互相访问，有一定安全风险。同时东西向流量也有不少消耗在健康检查上。期待这个部分后续的优化。

5. 对比结果一览

根据上述的对比分析，结果整理如下表所示：

项目华为 KubeEdge 阿里 OpenYurt 腾讯 SuperEdge 是否 CNCF 项目是(孵化项目)是(沙箱项目)否开源时间 2018.112020.52020.12 侵入式修改 Kubernetes 是否否和 Kubernetes 无缝转换无有未知边缘自治能力有(无边缘健康检测能力)有(无边缘健康检测能力)有(安全及流量消耗待优化)边缘单元化不支持支持支持(只支持 Deployment)是否轻量化是(节点维度待确认)否否原生运维监控能力部分支持全量支持全量支持(证书管理及连接管理待优化)云原生生态兼容部分兼容完整兼容完整兼容系统稳定性挑战大(接入设备数量过多)大(大规模节点并且云边长时间断网恢复)大(大规模节点并且云边长时间断网恢复)设备管理能力有(有管控流量和业务流量耦合问题)无无

3. 总结

各个开源项目，整个比较下来自己的感受是：KubeEdge 和 OpenYurt/SuperEdge 的架构设计差异比较大，相比而言 OpenYurt/SuperEdge 的架构设计更优雅一些。而 OpenYurt 和 SuperEdge 架构设计相似，SuperEdge 的开源时间晚于 OpenYurt，项目成熟度稍差。

如果打算选择一个边缘计算云原生项目用于生产，我会从以下角度考虑：

• 如果需要内置设备管理能力，而对云原生生态兼容性不在意，建议选择 KubeEdge

• 如果从云原生生态兼容和项目成熟度考虑，而不需要设备管理能力或者可以自建设备管理能力，建议选择 OpenYur