云原生边缘计算架构分析

云原生边缘计算架构分析

张琦¹，贾玄²，张森¹，殷薇¹，欧争光¹，王烽¹

（1. 华为技术有限公司，广东 深圳 518129；

2. 中国移动通信有限公司研究院，北京 100055）

摘 要：为解决日趋复杂的边缘应用管理带来的问题，在分析业界与学术界多个边缘计算项目的架构后，阐述了一种基于Kubernetes架构的云原生边缘计算系统KubeEdge。KubeEdge本质是将Kubernetes的云原生微服务管理能力延伸到边缘，将云原生的生态和开发体验延伸到边缘，针对上层开发者提供统一的开发、部署、管理视图，并增强了离线运行能力、边云协同能力和边边协同能力。最后，给出了在智慧园区、工业互联网、 互动直播、自动驾驶等场景下KubeEdge的实际应用案例，以及未来在边缘应用安全、数据隐私和可信以及边缘AI方向的研究工作。

关键词：边缘计算；云原生；边云协同；边边协同

中图分类号:

文献标识码:

doi:

Analysis of cloud native edge computing architecture

ZHANG Qi¹, JIA Xuan², ZHANG Sen¹, YIN Wei¹, OU Zhengguang¹, WANG Feng¹

1. Huawei Technologies Co. Ltd., Shenzhen 518129, China

2. China Mobile Research Institution, Beijing 100055, China

Abstract: In order to solve the problems brought by the increasingly complex edge application management, the architecture of multiple edge computing projects in the industry was analyzed and KubeEdge, a cloud-based edge computing system based on Kubnetes architecture was expounded. KubeEdge essentially extends Kubernetes' cloud-native micro-service management capabilities to the edge, extends the cloud's native ecosystem and development experience to the edge, provides unified development, deployment, management views for upper-level developers, and enhances off-line capabilities, collaboration capabilities crossing edge to cloud as well as edge to edge. In the end, practical applications of KubeEdge in smart campus, industrial Internet, interactive live broadcast, autopilot, etc. were given, as well as future research on edge application security, data privacy and credibility, and edge AI direction.

Key words: edge computing, cloud native, edge cloud collaboration, edge collaboration

1         引言

随着移动终端及物联网的技术发展和普及应用，当前万物互联的世界中产生的数据量将达到爆炸式的增长达到ZB级别，以云计算模型为核心的集中式大数据处理模型已经不能满足大带宽、低时延、数据隐私安全要求高的业务需要，为此，以边缘计算模型为核心的边缘式大数据处理应运而生^[1]。

当前边缘计算技术在智能工业、智慧医疗、智慧城市、智能交通与车联网、智慧物流及智能家居等领域已经有了初步尝试和应用，Gartner预测到2022年50%的大型企业将应用边缘计算技。随着边缘计算应用场景的日益增加和边缘设备产生的数据量的日益增多，边缘业务的复杂性日趋增高，为边缘应用的管理带来一系列挑战。

（1） 边缘应用开发、部署的便捷性要求增高，以满足边缘业务的快速发展和变化；

（2） 边缘应用需要有完善的微服务治理能力，以满足日趋复杂的边缘业务模型；

（3） 边云、边边的协同成为边缘应用的基本要求，以满足海量边缘数据的处理。

为了解决上述问题，本文将阐述一种边云、边边协同的CloudNative模式的边缘计算系统架构。

2         背景

2.1          发展现状

从边缘计算的发展历程来看，2015年前处于原始技术积累阶段，Cloudlet、雾计算、海云计算被相继提出；2015~2017年期间边缘计算快速发展，工业界发表了一系列的白皮书并成立了相关工作组及联盟，如欧洲电信标准化协会（ETSI）定义的多接入边缘计算（multi-access edge computing, MEC），思科、ARM、戴尔、英特尔、微软和普林斯顿大学成立的OpenFog联盟，华为技术有限公司、中国科学院沈阳自动化研究所、中国信息通信研究院、英特尔、ARM等成立的边缘计算产业联盟（Edge Computing Consortium）等。 2018年是边缘计算发展过程中的重要节点，在这一年边缘计算被推向前台。

2.2          学术界边缘计算平台研究

学术界关于边缘计算平台的研究主要有如下两个项目：Picasso和Discovery。

（1）Guifi Picasso

Guifi项目是由Cambridge University, UK发起，目标是为欧洲边远山区的民众搭建社区网络（community network），Picasso是Guifi项目的轻量级边缘计算平台部分。由市民、商户、学校、组织利用一些商用路由器以及Wi-Fi、光纤搭建了一个开放、互联的网络，并利用计算、存储资源构建了一个完整的去中心化云服务。

Picasso主要关注基于服务质量（quality，QoS）的服务调度、扩展和服务发现。使用了服务发现工具avahi（mdns/dns-sd）以及基于gossip协议最终一致性的消息组件serf（集群管理、消息传递），架构如图1所示。

 图1  Picasso架构

（2）Discovery Initiative

Discovery项目希望构建一个去中心化的基础设施即服务（infrastructure as a service，IaaS）管理平台，以应对管理地理离散的边缘计算节点的挑战。该项目基于OpenStack改造，通过替换集中式的数据库与消息组件为类P2P的redis cluster和zero MQ来支持当地理离散的节点增加时，资源管理性能的水平扩展。Initiative架构如图2所示。

图2 Initiative架构[l1] [o2] 

2.3          边缘计算开源项目

边缘计算得到了技术社区的大力支持，其中具有代表性的是以下4个开源组织及项目。

（1）LF Edge

LF Edge是Linux基金会的一个伞形组织，旨在建立一个开放、可互操作的边缘计算框架，它最初由5个项目组成，包括Akraino Edge Stack、EdgeX Foundry、Home Edge、Open Glossary of Edge Computing和Project EVE。LF Edege的边缘侧项EdgeX Foundry具备边缘数据收集云端汇聚功能，但当前并未关注边缘与云在应用开发、部署、管理、调度上的协同，不能很好地解决云与端的生态割裂。EdgeX Foundry架构如图3所示。

图3  EdgeX Foundry架构

（2）Eclipse IOT

2016年，Eclipse 基金会开源多个物联网项目，如图4所示，包括Eclipse Kura、Eclipse Paho、Eclipse OM2M以及Eclipse SmartHome。Eclipse 将物联网视为包括三层互联的软件栈。

l  设备应用软件的堆栈；

l  采集数据信息聚合的网关；

l  物联网平台后端的软件栈，通常包括云存储以及数据分析服务；

Eclipse IOT当前项目提供了大量的端侧与边缘设备的开发框架与中间件，边缘侧的项目iofog更偏重嵌入式基础设施平台及开发套件，而对端云一体的生态以及边云应用协同的开发、部署、管理、调度涉及不多，难以利用云端的强大计算能力和丰富服务。

图4 Eclipse IoT架构

（3）ETSI

欧洲电信标准化协会ETSI（European Telecommunications Standards Institute）定义MEC为multi-access edge computing，打造一个融合电信移动网络和云技术的边缘生态环境。ETSI MEC提出基于网络功能虚拟化（network function virtualization，NFV）的边缘计算架构如图5所示。

图5 ETSI MEC架构

未来5G核心网都会运行在NFV中，并且5G UPF提供相应的分流功能。基于这样的思路，ETSI提出在NFV上构造MEC的做法，对原有NFV体系架构进行补充。其优势是构造边缘计算的运营商和供应商能够很好地达成语言上的共识，缺点是未充分考虑最终用户的需求和使用习惯。

（4）CNCF

2018年11月，KubeCon上正式公布了新的基于Kubernetes的生态系统KubeEdge，将Kubernetes生态系统从云端扩展到边缘，将在本文第3节详细阐述。

3         云原生的边缘计算架构

3.1          整体架构和生态支持

Kubernetes是Google在2014年开源的容器编排调度系统，致力于支撑云原生应用的部署编排和为微服务运行提供所必须的基础设施。Kubernets的Edge Computing Working Group聚焦云原生技术和Kubernetes在边缘计算场景下的技术方案、参考架构已经构建端到端的验证设计并提供系统集成样例。本文所描述的云原生边缘计算架构便是该组织中的边缘计算参考架构，该架构由华为公司提出，于2018年11月宣布以KubeEdge为名开源，现已是CNCF官方项目之一。

KubeEdge基于Kubernetes的架构体系并针对边缘场景提供了诸如离线运行能力、边云协同能力等多种特殊能力的支持，将云原生的生态和开发体验延伸到边缘，面向开发者提供统一的开发、部署、管理视图，屏蔽边缘和云端的差异。其整体架构如图6所示。

图6 KubeEdge架构

（1）云端组件

为了兼容Kubernetes生态，云端组件采用标准的Kubernetes架构模式进行构建，架构核心基于Kubernetes的“预期状态模式”，处理步骤如下：

l  用户通过kubectl命令行发出对目标对象预期状态的指令；

l  Kubernetes的API Server接收到该指令，调度器会对其进行调度并将用户的指令分解为一系列新的带有“预期状态”的子对象；

l  新增加EdgeController和DeviceController通过API Server的“watch”接口订阅其所关心的对象，发现有新增对象或对象状态有更新则继续后续处理；

l  Controller将监听到的对象变动送给CloudHub组件，该组件维护一个边缘侧通过Websocket协议连接的列表，结合对象中的目的节点选择性地将该对象的元数据送至相应的目的边缘节点。

（2）边缘侧组件

为了进一步降低边缘侧的资源占用、出问题概率和维护难度，边缘侧组件本着“简单至上”的原则进行设计。所有的核心组件都运行于相同的进程内，将不同的功能组件定义为不同的模块（module），通过名为Beehive的框架统一管理，使用轻量级的go语言协程运行各个module。Beehive框架提供了模块的注册、发现、通信能力，在通信能力中又提供了同步、异步、单播、组播的能力以及通过go channel提供了进程内跨协程的通信能力和通过Unix Domain Socket提供了模块间跨进程的通信能力。

整体的边缘侧处理流程如下所示。

l  EdgeHub组件启动后主动发起与云上服务的连接，通过WebSocket协议构建一条长连接，接收云上下发消息并上报边缘的数据和状态；

l  接收到云上下发的某资源对象的元数据后，EdgeHub将该数据送给MetaManager模块；MetaManager模块统一管理云上下发的管理对象的元数据，使用SQLite数据库将数据进行持久化，并向其他动作执行模块提供查询接口，当对象元数据、状态等发生变化后，更新数据库中的相关数据；

l  Edged模块负责边缘端的应用管理，根据收到的应用对象元数据，通过Docker engine的接口启动相应的Docker容器，并管理容器的网络、存储、配置信息等；

l  DeviceTwin维护边缘侧的DeviceTwin数据，端侧设备的数据通过Mapper收集至该模块，DeviceTwin负责将数据进行持久化并对云上和边缘侧的其他应用提供标准化的数据访问接口。

l  EventBus负责维护一个内置Mqtt Broker的数据转发，并且可以使用Bridge模式对接一个外置的Mqtt Broker。边缘侧其他应用产生的数据或收集到的端侧设备的数据经EventBus转发至云上或其他边缘侧模块。同时，Edge-core中的其他模块需要与边缘侧其他应用以Mqtt消息的方式（推荐的边缘侧消息交互模式）进行交互的时候都需通过该模块进行。

l  ServiceBus的定位同EventBus，负责通过REST服务的形式联通云端和边缘侧的应用。当边缘侧的REST服务没有公网IP时，云上的REST请求可以通过KubeEdge提供的WebSocket连接传送至边缘侧，ServiceBus负责将该请求转发至正确的边缘应用，而后将Response返回至云上相应的请求发送方处；

l  Mapper和DeviceTwin共同构成了物理设备的世界到数字世界的映射。Mapper通过不同设备协议与其相连并将数据按照DeviceTwin的格式转换为DeviceTwin模型数据，通过Mqtt Broker将数据送入DeviceTwin模块供其他应用访问。

3.2          支持复杂的部署模型

Kubernetes在多年的发展中已经积累和沉淀了一些对云原生应用的编排部署模型，KubeEdge将这些编排部署能力延伸到边侧，支持边缘侧日益复杂的业务和高可用性的要求。

Kubernetes的整体模型如图7所示，在图7中可以表现大多数的云原生编排部署能力。

图7 Kubernetes对象模型

l  双机热备

在一些存储持久化的场景中，例如MySQL双机热备的场景，利用stafulset的机制，在应用重新调 度后MySQL应用还能被调度到原有的节点之上，保证访问同样的存储。

l 多机多活互备

可以利用replicaset创建多个副本，replicaset可以维持设定副本数的应用同时运行。

l  有关联的应用同节点部署以提升应用间交互效率

使用POD亲和性调度规则，可以把相关的应用部署在相同的主机上以提升通信性能。

l  同一应用的不同实例跨节点部署以提升可用性

利用POD反亲和性特性，可以选择同一应用部署的不同实例分散在不同节点上进行部署。

l  依据边缘节点的不同属性将应用部署于不同分组中

在很多场景中依据边缘节点的地理位置、设备类型、功能属性、性能等分属于不同的分组，打上不同的标签，在应用部署时利用node selector的能力将应用部署在对应label上的边缘节点之上。

l  定义独立于节点的应用部署以实现满足条件的新边缘节点上线后自动安装应用

在应用部署时，应用根据节点的label去将应用部署在对应的节点之上，当新的节点上线后，可以将其打上同样的label，节点上线之后K8S系统可以立刻将应用自动部署在新上线的边缘节点之上。

3.3          使用edgemesh支持跨越边界的微服务访问

随着微服务框架的流行和边缘节点计算和网络能力的增强，把部分服务部署到边缘处理设备产生的数据可以解决时延的问题，但由于安全等原因，大多数服务仍然运行在云上，云跟边、边跟边之间的协同是必须要解决的问题。edgemesh微服务框架如图8所示，edgemesh主要解决了两个问题。

l 由跨越了边、云而组成的大型分布式系统中的微服务之间互相发现和访问；

l 在微服务互相访问的过程中对访问过程进行治理、控制从而提升大型分布式系统整体的可用性。

[l3] [o4] 

图8 edgemesh微服务框架

（1）边边协同

边边协同原理如图9所示。

[l5] [o6] 图9 边边协同

l 在k8s中创建Service，设置label；

l edgecontroller watch到Service的事件，同步到edgehub，经metamanager保存到SQLite；

l 用户应用A跨接点请求用户应用B时，流量通过iptables规则全部劫持到edgemesh；

l edgemesh解析应用层协议，调用metamanager查询Service/Endpoint/Pod等相关信息，根据负载均衡等策略选择目的地址，封装请求为“beehive/pkg/core/model”。Message并转发请求到目的节点的edgemesh；

l 目的节点edgemesh解析“beehive/pkg/core/model”。Message并根据配置的QPS策略处理请求，转发请求到用户边缘应用B。

（2）边云协同

边云协同原理如下图10所示。

[l7] 

图10 边云协同

l 在k8s中创建Service，设置label；

l edgecontroller watch到Service的事件，同步到edgehub，经metamanager保存到SQLite；

l 用户应用A跨接点请求用户云上服务B时，流量通过iptables规则全部劫持到edgemesh；

l edgemesh解析应用层协议，调用metamanager查询Service/Endpoint/Pod等相关信息，根据负载均衡等策略选择目的地址，封装请求为“beehive/pkg/core/model”。Message并转发到edgecontroller；

l edgecontroller解析“beehive/pkg/core/model”，Message根据配置的QPS策略处理请求，转发请求到用户云上服务B。

4         应用情况介绍

4.1          智慧园区

智慧园区项目基于华为云智能边缘平台IEF（intelligent EdgeFabric，KubeEdge的商业版）服务在边缘侧部署人脸识别、人员轨迹分析、事件报警管理等边缘应用，大幅度降低视频上云对网络带宽的诉求。

智慧园区如图11所示，视频分析算法以容器的方式快速部署到边缘节点，并同云上的人脸检索等服务对接形成边云协同的智能视频分析服务。基于IEF可以实现边缘算法的动态更新及灰度升级。

图11 智慧园区

4.2          工业互联网

某合成纤维领域的高新技术企业使用IEF实现生产状态的实时监控和产品质量的实时预测，提升产品质检的检测效率，提高产品质量，减少生产线故障率。

工业互联网如图12所示，将工业视觉质检应用部署在边缘节点以满足工业级实时性，同时部署数据预处理应用将数据脱敏后上传到云上训练，并实时更新边缘模型，提高推理精度。

图12 工业互联网

4.3          互动直播

互动直播如图13所示，某视频直播企业在CDN侧通过华为智能边缘平台IEF部署视频转码、渲染、切片等多个边缘微服务，对数据进行预处理，减小向中心服务器传输数据量，降低网络传输成本；为了提升边缘微服务的高可用性，通过IEF的边边协同能力实现边缘微服务跨边缘站点的负载均衡和自动伸缩。

图13 互动直播

4.4          自动驾驶

自动驾驶如图14所示，自动驾驶是典型的云边端协同架构。汽车车体上拥有各种传感器如图像传感器等，通过5G信号传输到就近的边缘服务器上，对数据转换和初步分析、推理，处理后的关键数据上传到云端，进行进一步推理预测和训练。

依赖于5G和边缘计算，实现了车辆的自动驾驶和车联网。云边端的协同，是时延、数据量、计算量的三重均衡结果。采用云原生架构，可更加灵活地分配计算量和数据量，并满足时延的需求。

图14 自动驾驶

5         未来的工作

边缘计算方兴未艾，未来研究方向广阔，例如：

（1）安全

传统应用运行在数据中心，通过一个统一的入口对外提供服务，而边缘应用部署在一个不可信的环境中，这种方式给应用和数据安全带来了极大的挑战。边缘节点与中心云通过公有网络或专线联通，采用防火墙、安全组等传统方式进行保护，近年兴起Zero Trust 网络和SDP（软件定义边界software defined perimeter），或许是适于边缘节点的一个方向^[2-3]；

（2）数据隐私和可信问题^[6]

一种尝试是可信计算，在TEE（如ARM Trustzone）中对数据进行加密再传输，应用运行在TEE中进行解密、处理；另一种可行的尝试是多方计算MPC和同态加密；

（3）边缘AI

当前流行云上训练、边缘推理模式，实际上由于数据隐私和网络带宽问题，大量数据分布在边缘，分布式机器学习或联邦学习^[4-6]在边缘对数据进行训练、中心进行协调，可能成为一个重要方向。

6         结束语

本文阐述的云原生边缘计算架构将云原生应用无缝延伸到靠近数据产生位置的边缘侧，实现了边云、边边之间的应用协同和统一微服务治理，从而应对日趋增高的边缘应用复杂性对应用开发、部署、管理、协作维度带来的挑战。本文结合实际应用案例完整地描述了云原生边缘计算的架构，同时给出了面向边缘应用安全、数据隐私和可信以及边缘AI等下一步的研究方向。

参考文献[l8] [o9] ：

[1]      施巍松, 孙辉, 曹杰, 等. 边缘计算：万物互联时代新型计算模型[J]. 计算机研究与发展, 2017, 54(5):907.

WEI W S, SUN H, CAO J, et al. Edge computing — an emerging computing model for the internet of everything era[J]. Journal of Computer Research and Development, 2017, 54(5):907.

[2]      PUTHAL D, NEPAL S, RANJAN R, et al. Threats to networking cloud and edge datacenters in the internet of things[J]. IEEE Cloud Computing, 2016, 3(3): 64–71.

[3]      PUTHAL D, MOHANTY S P, NANDA P, et al. Building security perimeters to protect network systems against cyber threats [J]. IEEE Consumer Electronics Magazine, 2017, 6(4): 24–27.

[4]      MCMAHAN B, RAMAGE D. Federated learning : collaborative machine learning without centralized training data. Post, 2017: 1.

[5]      LI P, LI T, YE H, et al. Privacy-preserving machine learning with multiple data providers[J]. Future Generation Computer Systems, 2018, 87: 341-350.

[6]      SMITH V, CHIANG C K, SANJABI M, et al. Federated multi-task learning[J]. 2017: 4424–4434.