开源边缘计算平台研究分析

Posted 2022-01-03 边缘计算社区

  摘要： 

从边缘计算平台现状背景开始， 以CNCF内OSF小组定义的2类边缘计算平台架构为抓手，从系统架构、核心优势、未来路线方向详细分析开源平台KubeEdge、OpenNESS、和OpenYurt，并对比分析上述开源平台技术特点，最后对标相关标准组织3GPP、ETSI定义，映射分析上述开源平台，提出运营商在开源平台技术方向实施建议。

  引  言  

2020年，5G商用引爆通信业发展。以往通信设备都是软硬件一体，一旦标准技术换代，就得研制新设备，导致投资大、灵活性差。5G引入SDN/NFV技术后，采用标准服务器、存储器和交换机来承载软件化网络功能，替代原有软硬件一体专有设备，解决了通信设备迭代更新难度大问题。随着5G不断向软件定义网络方向发展，网络架构变得更加灵活，为了适应这种变化，传统CT、IT、公有云厂商也适时推出了开源边缘计算平台项目。

01

边缘计算平台现状

万物互联时代到来，边缘计算规模和业务复杂度发生了根本变化：边缘实时计算、分析和边缘智能等新型业务不断涌现，对边缘计算效率、可靠性和资源利用率提出了更高要求；因此，诸多厂家提出建设边缘计算平台，平台涉及边缘侧网络、计算以及存储资源管理，提供基础功能，如设备接入、安全校验、监控等，其接口、架构、管理逐步成体系。但各厂家的边缘计算平台差异较大，行业边缘应用部署时需要适配不同边缘计算平台，导致跨平台应用部署难度大，故考虑引入开源技术打造5G MEC边缘计算架构和能力开放的事实标准，打破当前边缘计算平台市场烟囱式、碎片化现状，降低产业应用客户上车门槛，实现规模复制，通过开源协作方式构建统一5G MEC平台。下文从边缘计算平台参考架构入手，引出2种开源边缘计算平台进行分析。

02

典型边缘计算平台参考架构

2020年，在OSF边缘计算小组（Open Stack基金会主导）发布的《边缘计算：架构，设计和测试的下一步》白皮书^【1】中，开源基础设施运营商和供应商联合定义了以下2类典型边缘参考体系结构模型。

a） 集中式控制平面模式：传统单数据中心环境下中心控制器和边缘计算节点由广域网连接。该模式从集中运营角度看有优势，安全性高，但节点严重依赖集中式数据中心来承载管理和协调边缘计算、存储和网络服务，边缘节点自主性差，是一种传统架构模式。

b） 分布式控制平面模式：多数控制服务驻留在大/中型边缘数据中心上，也要求边缘站点自身功能全面。这种体系结构比较灵活，尤其在网络连接丢失情况下更凸显其优势，但由于需要跨地域运行大量控制功能，管理编排类型服务更复杂。KubeEdge和StarlingX属于此类去中心化架构模式^【2】。

03

开源平台项目分析

KubeEdge、Open NESS是市面上较为常见的几类开源平台，均采用了通用VNF Manger和NFV Orchestrator组件，参考了标准ETSI  MANO体系结构，但其特点不尽相同，详细分析如下。

3.1  KubeEdge

2019年，由华为捐给CNCF基金会，基于 Kubernetes（简称k8s）构建，100%兼容k8s API，是Kubernetes IoT Edge WG关键参考架构之一,可提供云边协同能力开放。

3.1.1  整体架构

该平台分为云端、边缘端和终端三层，解耦式的架构，具体如图2所示。

a） 云端：负责应用和配置策略下发，通过旁路设计开发CloudCore组件，进行边缘节点同步和维护，利用list watch与Kubernetes集群做信息同步。

b） 边缘端：负责运行边缘应用和管理接入设备。Edgecore支持CRI，底层可以对接多种container runtime、device Twin和DEvent Bus，主要是做设备元数据管理以及MQTT协议订阅和发布，从而完成与终端设备通信。

c） 终端：运行各种边缘设备。设备终端有多类访问协议，部分新设备可能直接支持MQTT协议。但部分专用设备存在专用协议，KubeEdge采用Mapper设计，可将专有设备协议转换成MQTT协议，实现边缘应用和云上设备数据同步和管理^【3】。

图1  KubeEdge整体架构

3.1.2  主要特点

KubeEdge针对边缘侧实际环境做了诸多优化。

a) 云边可靠协同：采用双向多路复用消息通道，支持边缘节点位于私有网络中，云边消息传输默认使用websocket消息封装，减少通信压力，高时延下仍可正常工作。

b) 边缘离线自治：通过消息总线和元数据本地存储实现节点离线自治，节点故障恢复也无需list-watch,从而降低网络压力，提升故障恢复速度。

c) 边缘极致轻量化：边缘侧节点Edgecore内存约70M，支持CRI集成containerd和CRI-O,优化了runtime资源消耗，方便在资源受限边缘上运行；保留了 Kubernetes的管理面，重新开发了节点 agent，大幅降低边缘组件资源占用率。

d) k8s原生支持：云端可以通过k8s API管理边缘设备和边缘应用程序。

但是作为一个开源项目，KubeEdge仍有很多方面待继续完善。

a) 不支持设备协议如OPC-UA。

b) 不支持使用数千个Edge节点和数百万个设备评估并启用更大范围的Edge群集。

c) 不支持对大型Edge集群的应用程序进行智能调度^【4】。

3.2  OpenNESS

由Intel主导，是一套开源软件开发套件,为在用户边缘侧或网络边缘侧等位置运行的应用提供单一应用托管环境，旨在多种网络接入方式（WiFi/4G/5G等）下助力边缘业务管理与编排，通过抽象化去除网络复杂性，让开发人员可以像编写云软件一样轻松编写适用于边缘的软件，该项目在Akraino Edge Stack（Linux基金会项目）中被广泛应用^【5】。

3.2.1  整体架构

OpenNess由边缘节点和边缘控制器2个部分构成^【6】。

a） 边缘节点：支持多种网络接入方式，能够从IP、SI_U或者SG1接口提取数据；支持针对5G延迟、多租户和服务注册流量定向，并支持部署边缘应用。

b） 边缘控制器：一般处于数据中心、云中或边缘等位置，进行边缘平台编排，采用GUI方式，支持其他通信服务提供商采用API方式链接到自己的控制器GUI环境。图3为OpenNESS抽象描述，展示边缘节点上软件和云控制器与其他技术相互配合的使用方式。

图2  OpenNESS整体架构

3.2.2  主要特点

OpenNESS当前侧重4G/5G功能集成、底层Cloud native能力以及不同硬件资源适配能力。

a） 支持独立5G NR和增强平台感知部署。有5G接入模块，AF可与NEF通过N33接口或者与PCF通过N5接口通信，帮助MEP下发分流规则以及事件订阅等，支持HTTP/2 HTTPS/oAuth2协议；OpenNESS的DataPlane模块是所有边缘开源项目中比较独特的。

b） 高效扩展简化编排：可以与Kubernetes（将来还包括Openstack）配合使用，可用于预配边缘资源并为网络边缘配置增强型平台感知功能，虽然本身不包含服务编排，但具备可连接到服务编排器的控制API。

c） 提供应用使能服务能力：提供API，可供应用实现服务注册、发现、订阅和已订阅服务查询。

d） 灵活扩展性强，多云兼容：基于微服务和开源API，OpenNESS可以为 AWS Green grass、Microsoft Azure IoT Hub和百度IntelliEdge提供云连接器，因此更易于实施升级和更新管理^【7】。

3.3  对比分析

整体来看，各平台涉及技术栈基本一致，但在部署形态、架构、编排策略、可靠性和应用场景等方面仍有差异（见表1），因此未来多平台共存将是常态，如何加强各平台间的协作将是未来的研究重点。

表1：开源边缘计算平台性能分析对比

04

3GPP& ETSI边缘计算平台架构映射分析

4.1  3GPP

3GPP主要关注的是网络架构对MEC特性的支持，其中5G 网元UPF作为边缘计算的数据锚点、涉及用户面重选、灵活业务疏导和计费等服务质量保障方面内容；MEC与5G的融合架构主要关注3个接口：MEC平台与NEF的接口 N33，与PCF的接口N5，与UPF的接口N6。目前由Intel开发的OpenNESS平台也已经搭建了5G+MEC测试床。

4.2  ETSI

ETSI定义MEC为在移动网络边缘提供IT服务环境和计算能力。MEC架构设计遵守基础资源开放、平台能力开放(通过MP1 接口，为APP提供ME services )、网络能力开放（RNS API、Location API、bandwidth API、UE identity API）、管理能力开放、本地流量卸载以及移动性管理这几个原则。

4.3  部分开源平台映射关系

OpenNESS符合ETSI MEC框架，其中边缘控制器对应MEPM,边缘服务对应MEP,边缘应用对应ME APP。OpenNESS主要参考ETSI  MEC规范，OpenNESS与ETSI的映射关系如图9所示，其中蓝色及橘色部分由OpenNESS实现^【13】。

图3  OpenNESS与ETSI的映射关系

05

运营商实施建议

随着企业大步向云原生时代迈进，电信运营商也逐步将云原生技术扩展到边缘侧，并密切关注全过程中的安全性、服务遥测、计算性能、弹性和扩展性，以便未来以开放互操作的方式调整组织、业务和运营流程，加快部署节奏，降低总成本和运维风险^【11】，笔者建议如下。

a） 提供统一边缘计算参考实现标准，聚焦整体框架、接口定义及实现方式，并进一步统一面向应用的接口，降低应用开发伙伴上车门槛，逐步打破各家烟囱式MEC方案，打破市场隔离。

b） 积极与公有云厂商合作，作为当前公有云服务提供商的补充，可避免重复部署资本密集型基础设施，实现快速上市和测试新行业用例，共享行业应用程序生态系统资源。

c）重点关注边缘计算平台的异构硬件支持、移动性支持、IT/CT鸿沟的关键技术点以及平台是否支持边缘节点轻量化部署和边缘离线自治^【13】。

总体看来，当前边缘计算相关创新和开源化进程仍处于早期阶段。虽然开源将打破旧有设备供应链格局，但在开放架构下，如何加强各开源平台间协同创新，保障各方利益，平衡开源和专利保护，这些有待进一步研究与探讨。

参考文献

【1】Beth Cohen，Gergely Csatári，Shuquan Huang，Bruce Jones，Adrien Lebre，David Paterson，Ildikó Váncsa.Edge Computing: Next Steps in Architecture, Design andTesting[EB/OL].https://www.openstack.org/use-cases/edge-computing/edge-computing-next-steps-in-architecture-design-and-testing/?lang=en_US,2020.

【2】梁家越,刘斌,刘芳.边缘计算开源平台现状分析[J].中兴通讯技术 边缘计算专刊,2019,25(3):12-18.

【3】开源社区.KubeEdge官网[EB/OL].https://github.com/kubeedge/kubeedge,2019.

【4】HarmonyCloud.干货满满 | 谐云在KubeEdge云边协同落地实践分享 [EB/OL].https://mp.weixin.qq.com/s/Jh74RSMbrKG2WrKjv1XAVA,2020-09-01.

【5】官网.openness介绍[EB/OL].https://www.openness.org/

【6】Intel.openness-and-the-network-edge-eguide-cn[Z].global:Intel,2020-4.

【7】高纪明.OpenNESS基于云原生的一体化MEC解决方案[Z].中国:INTEL,2020-8.

【8】官网.StarlingX项目介绍[EB/OL].https://www.starlingx.io/learn/,2019.

王毅.时间敏感网络在StarlingX的集成方案介绍[Z].中国:INTEL,2020-8.

【9】开源社区. openyurt官网[EB/OL]. https://github.com/alibaba/openyurt,2020.

【10】新胜.深度解读. OpenYurt：从边缘自治看 YurtHub 的扩展能力[EB/OL].https://mp.weixin.qq.com/s/b0gGlXvXRS3hz9vRrqSFnQ,2020-07-10.

【11】高维涛.由CloudNative引发的思考：什么是EdgeNative（边缘原生）[EB/OL].https://mp.weixin.qq.com/s/7HgUiGuboLDhqdCLh415bA,2020-09-07.

【12】开源中文社区.电信公司，在考虑云原生、边缘时请注意这5个问题[EB/OL].https://mp.weixin.qq.com/s/4QAhNukaCEV3Ivz6Vyiorg,2020-09-03.

【13】TEF,DT,HTK,etc.GSMAFutureNetworksProgrammeOperatorPlatformConcept_Whitepaper[R].london:GSMA,2020.

作者简介：

黄倩，工程师，硕士，从事边缘计算，开源技术，5G标准化工作，5G垂直行业咨询工作；

黄蓉，高级工程师，博士，从事白盒基站，边缘计算工作；

陈杲，高级工程师，博士，从事边缘计算技术研究工作；

王友祥，高级工程师，博士，从事5G/6G新技术及产业推进工作；

编辑：李星初

审核：薛海斌

来源：邮电设计技术

编辑：边缘计算社区

边缘计算社区：促进边缘计算领域知识传播，中立，客观，如果您关注边缘计算、5G、物联网、云原生等领域请关注我们。