云原生边缘计算产品与项目分析

杨秋霞 赵 斌 栗 霖 隗英英 常 乐

中国联通智网创新中心 北京 100044

引言

边缘计算作为一个5G网络中的关键技术，能够托管计算密集型应用程序来优化移动资源，在靠近移动用户的无线接入网提供云计算服务，在数据上云之前处理大数据。边缘计算具备如下突出的优势：首先，数据在源头就近处理，极大地减轻了网络带宽和数据中心的压力；其次，服务请求不需要等待云计算中心的处理结果，减少了网络延迟，提升了服务质量。尤其在一些实时响应要求高的场景，如自动驾驶、AR/VR、远程医疗等，利用边缘计算发挥网络超低时延的优势，被视为未来计算的新兴趋势。可以预见在5G网络下，计算和流量的需求有巨大的增加。

随着计算密集型和时延敏感型应用程序的快速发展，万物互联逐渐成为物理设备协同计算的发展趋势。终端用户的存储容量有限，处理能力不足，在资源受限的用户设备上运行计算密集型程序面临挑战。通过边缘计算可以实现多边缘设备之间的协同，边缘与边缘之间的相互协作可以减轻单一边缘节点的计算压力，解决边缘设备受限于资源的问题[1]。

由于边缘计算潜在价值巨大，全球主要国家竞相角逐边缘计算赛道。美国五大科技巨头Facebook、Amazon、Microsoft、Google和Apple依托其自身业务范围，制定各自的边缘基础架构，投入边缘应用研发。欧盟主要成员国开展了一系列架构研究工作，以边缘计算为中心的“欧洲云”项目旨在国家层面与美国、中国等企业形成战略平衡[2]。欧洲边缘计算产业联盟(ECCE)将推动在制造业、运营商以及企业与IoT等相关领域提供全方位的边缘计算产业合作平台。我国也积极投入边缘计算产业发展，中国边缘计算产业联盟(ECC)成立于2016年，覆盖几乎所有主要行业，同时成立技术标准、测试、安全、市场推广等工作组。国内从业者积极投身边缘计算，其中包括三大运营商、网络设备提供商(中兴、华为等)以及中国大型云服务企业(阿里巴巴、腾讯和百度等)。

从2018年开始，边缘计算进入到稳健发展期。超大规模云计算环境中已被普遍使用的Kubernetes被引入到边缘计算场景，云原生的理念也逐步为边缘计算所运用。本文将阐述云原生边缘计算的意义，在此背景下，分析云厂商近几年的代表性产品AWS Wavelength和边缘节点服务。同时借助开源项目OpenYurt、KubeEdge、k3s、Virtual Kubelet，阐述云原生边缘计算的技术方案。最后，结合目前运营商在边缘计算领域的已有探索，给出运营商参与边缘计算的建议。

1 云原生边缘计算背景

近年来，云原生逐渐成为工业界的共识。尤其是疫情的爆发和持续，全面催化了企业应用“生于云，长于云”的业务升级。边缘计算融合云原生相关技术，将云原生理念延伸到边缘，拓展边缘的服务能力，也得到了产业界的广泛关注。

云原生赋能边缘计算具有现实的需求和实际的意义。海量的终端设备、多元化的智能产品被应用到生产、生活的各个场景，典型的硬件包括CPU(ARM或X86)、GPU、NPU等，这些异构硬件对边缘计算提出更多样化的挑战。边缘云不同于大型数据中心，算力、存储资源相对较少，更适合轻量化和敏捷的服务部署方式。将大型应用分解为模块，进行模块化部署可以更适用于边缘资源有限的场景。云边协同需要边缘设备被纳管到中心集群，而且边缘要具有一定的自治能力，做到云与边之间的协调与同步，高效的编排管理能力不可或缺。

云原生的要素适用于边缘计算。容器是一种运行在宿主机上的特殊进程，不依赖于操作系统，运行环境被隔离，资源受宿主机限制。容器体量轻巧，部署启动便捷，便于集成。异构计算时代，已有异构资源分层抽象等技术来实现容器化的设计架构。通过微服务将庞大的单体应用解耦为更小的、互相连接的功能单元，微服务架构的设计思想即要求核心的能力内聚、独立，很少地依赖系统环境，分散部署。这一思想契合边缘计算充分下沉、分布式计算等特点。借助Kubernetes编排引擎实现边缘应用自动化部署、升级、运维，实现统一的交付、运维、管控，契合云原生持续交付、DevOps理念。

由于云原生技术天然适配边缘计算的场景，因此在产业界普遍基于云原生来开发相关的边缘计算产品。AWS Wavelength和阿里云ENS(Edge Node Service，边缘节点服务)是公有云厂商研发的边缘计算产品；OpenYurt、KubeEdge、k3s、Virtual Kubelet为开源的云原生管理项目，可以将云原生能力拓展到边缘。本文将重点分析这些边缘计算产品和开源项目的设计理念及技术架构，希望推进这些产品和开源项目的落地应用。

2 云原生边缘计算产品分析

2.1 AWS Wavelength

AWS Wavelength是一款针对移动边缘计算应用程序优化的AWS基础设施产品，能在全球多个5G网络中提供一致的体验，用户可以访问5G网络边缘的各种云服务[3]。亚马逊通过与全球范围内多家运营商(Verizon、KDDI、SKT)合作，将AWS云服务(如计算服务EC2、存储服务gp2、容器服务Kubernetes)推向运营商的5G网络边缘，从而为用户提供5G网络边缘计算能力。

5G设备的应用流量可以通过5G网络到达AWS Wavelength中运行的应用服务器，这就避免了因应用流量必须遍历互联网中的多个节点才能达到其目的地而导致的延迟，从而使客户能够充分利用现代5G网络提供的低延迟和大带宽优势。

用户使用AWS Wavelength可以获得和AWS云端一致的操作体验，用户登陆AWS的管理控制台操作AWS Wavelength，可以完成虚机实例、存储、网络等创建任务。

AWS Wavelength可用于低延迟的服务和应用程序的部署访问，因此用户不需要在AWS Wavelength中部署整个应用程序，只需要部署可从A W S Wavelength中受益的应用程序部分，例如要求低延迟的应用程序组件。

在AWS Wavelength中的计算资源上可部署AI应用。综合考虑资源分布不均衡和推理延迟的不同需求，在设计云边协同系统时可以分区域发布服务。边缘计算设计目标之一是对推理请求的低延迟处理，因此将API服务器和推理服务器部署于AWS Wavelength中。另一方面，Web服务仅服务于结果可视化，由于没有与推理处理相同的延迟要求，因此Web服务托管在“AWS中心云”，减少AWS Wavelength网络压力。

以图像目标检测为例(如图1所示)，API服务器接收来自5G终端的图像，并将图像转发到推理服务器。推理服务器返回检测到的对象以及该对象的位置坐标，API服务器在图像上添加文本标签和检测框，然后将处理后的图像返回给5G终端。

图1 AI应用在Wavelength区域部署架构

2.2 阿里云ENS

阿里云边缘节点服务ENS提供了一种基于各城市运营商全网覆盖、下沉至靠近终端用户侧的弹性分布式算力资源[4]。传统的中心化云服务已经不能满足所有业务需求，部分应用对带宽和时延较为敏感。如果用户侧一次性承担算力，不仅加大用户使用成本，而且不能弹性扩展，无形中提高了业务开展和预算投入的门槛。阿里云ENS产品能力赋予云原生在边缘领域所依赖的云技术底座，使边缘侧保持和中心云一致性体验，具备更高效、低延时的性能。

阿里云ENS分布式边缘节点同样具备中心云弹性伸缩等优点，用户可按需定制计算、存储、网络等资源，一键快速批量下发全国边缘算力。相比于传统中心云，阿里云ENS具备更好的低延时特性，支持更广范围的业务场景应用，且本地化方案比中心带宽成本降低30%，与自建节点相比[5]，用户使用阿里云ENS前期可投入较少的资金和人力。其“极简运维能力”提供一种可批量、可视化、自动化的运维方式。用户随时随地监控边缘资源使用状态，并进行有效运维保障。

阿里云ENS所具备的全网广覆盖、流量本地化、低延时等特性可赋能众多典型场景，包括互动直播、CDN(Content Delivery Network，内容分发网络)、在线教育、视频监控、本地IT上云等(如图2所示)。对于计划自建机房的用户，面临重资产一次性高投入、运维难度大的问题，而且资源无弹性，难以应对突发高峰情况。对于视频互动实时性敏感的场景，视频上中心云体验并不理想。业务下沉到阿里云ENS汇聚节点，将会解决上述瓶颈，而且降低成本。当然，边缘云的各种优势不能全盘否定中心云的重要性，未来更多的场景会采用中心云+边缘云业务融合的方式，将业务根据算力、延时、成本、安全等进行合理拆分，分别部署至云和边，实现更具竞争力的应用产品。

图2 阿里云ENS设计理念

综合上述分析介绍，对AWS Wavelength和阿里云ENS两款产品进行对比，结果如表1所示。

表1 AWS Wavelength与阿里云ENS对比

3 云原生边缘计算开源项目分析

3.1 OpenYurt

阿里云原生边缘计算解决方案OpenYurt是一款云原生边缘计算框架。主打“云边一体化”概念，本着“Extending your native Kubernetes to Edge”的设计理念，通过非侵入式增强Kubernetes，保持和云原生社区的技术同步，延伸原生Kubernetes的能力到边缘，获得边缘集群能力[6]。

OpenYurt架构分为云端和边缘端两部分(如图3所示)，主要设计理念为云端的Master节点，负责管理在边缘端的节点。边缘节点可以跨越多个物理区域，负责管理相应的边缘计算资源允许运行多个边缘应用程序和节点守护进程。

图3 OpenYurt架构

边缘计算的重点在于边缘侧与中心云协同计算，包括六个方面：资源系统、数据协同、智能协同、应用管理协同、业务管理协同和服务协同。云边协同强调了边缘计算与云计算的组合和定位，需要深度融合计算与网络资源，解决算网分离的问题。

解决上述问题需要边缘侧具有自治能力，即当云边网络断开或者连接不稳定时，确保边缘业务可以持续运行。在OpenYurt中，该能力由图3所示的yurtcontroller-manager和YurtHub组件提供。在提供边缘自治能力的基础上，OpenYurt还在节点和云端之间提供了相互加密的隧道和反向代理。当入口流量由于网络策略而被阻止时，云端节点仍然可以检索心跳并监视工作负载。这将有效地解决各种原因致网络不可达的问题，为云边协同计算提供了保障。

此外，OpenYurt秉持着“最小修改”原则，对Kubernetes零侵入，基于标准Kubernetes API及标准网络技术实现，使得其具有强兼容性，易于集成，提供一键集群转化功能，最大程度保证用户在管理边缘应用时获得和管理云端应用一致的体验。

目前，OpenYurt已经持续迭代至V0.4.0版本，除提供上述能力外，还提供了边缘本地存储管理，边缘IoT设备管理等全新能力，且对Kubernetes1.18版本进行了支持，以及一系列扩展能力和优化。

3.2 KubeEdge

KubeEdge是华为云开源的智能边缘项目，是首个基于Kubernetes扩展的、提供云边协同能力的开放式智能边缘平台[7]。KubeEdge旨在解决一些网络受限、只有内部私网地址的边缘场景。这些场景的边缘侧算力往往不高，而且需要兼容更多样的设备接入，但对网络时延要求较低。KubeEdge是一种轻量化的、能够实现一致的设备管理和接入体验的云边协同架构，底层支持资源异构，可进行大规模边缘节点的接入。

KubeEdge架构分为三层，分别是云端、边端和设备端(如图4所示)。KubeEdge的云端进程包含以下2个组件：1)CloudHub用于接收EdgeHub同步到云端的信息；2)EdgeController负责控制Kubernetes API Server与边缘的节点、应用和配置的状态同步。

图4 KubeEdge系统架构

KubeEdge的边缘进程包含以下5个组件：1)Edged是个重新开发的轻量化kubelet，实现Pod、Volume、Node等Kubernetes资源对象的生命周期管理；2)MetaManager负责本地元数据的持久化，是边缘节点自治能力的关键；3)EdgeHub是多路复用的消息通道，提供可靠和高效的云边信息同步；4)DeviceTwin用于抽象物理设备并在云端生成一个设备状态的映射；5)EventBus订阅来自于MQTT Broker的设备数据。

另外，KubeEdge实现云边协同，可支持边缘节点位于私有网络。重组的Kubelet模块使得边缘侧极致轻量化，降低边缘侧的使用负载。将设备进行抽象化，极大方便了设备的接入和管理。

KubeEdge利用云原生架构的优势，提供一种高效率、高扩展性的云边协同技术方案，在边缘计算领域赋能各个行业并提升业务价值，比如智慧园区、构建CDN、工业互联网和车联网等。通过中心云统一控制全国边缘站点，实现应用和资源一点分发和部署。采用KubeEdge云原生架构，可权衡云边端时延、数据量、计算量多种因素，资源灵活分配，并具有良好的离线自治性。

3.3 k3s

k3s是一套基于Kubernetes的轻量化云原生框架，在边缘节点资源有限时，Kubernetes本身会消耗大量的计算资源，导致节点利用率偏低，此时就需要一个轻量化的云原生应用[8]。k3s通过移除Kubernetes非必要的功能、删除插件、使用Containderd替Docker等方式，使得k3s的二进制文件包小于60Mb，只需要512MB RAM即可运行。并且k3s同时支持x86_64、ARM64和ARMv7架构，在资源有限的情况下，使用k3s能够有效的提高边缘节点的资源利用率。k3s较低的资源需求使其可以完整的部署在一个边缘节点上，k3s和OpenYurt、KubeEdge等开源的边缘云原生框架相比，其自身缺少了边缘计算所需的云边协同和边缘自治的特性。

在实际使用时，由于k3s全部部署在边缘节点上，边缘节点之间互不统属，不提供云边协同的能力，因此k3s需要一个集群管理方案负责跨集群的应用管理、监控、告警、日志、安全和策略等，其云边协同架构如图5所示。k3s的开发公司Rancher提供了Rancher管理平台，在Rancher管理平台可以实现边缘节点的统一纳管，以及边缘节点的业务部署及开通，Rancher管理平台负责跨集群的应用管理、监控、告警、日志、安全和策略。若向集群添加节点，用户只需要在新的节点上通过一条命令指向原始服务器，通过安全token传递即可，十分便捷与高效。目前Rancher管理平台已经将开源的版本更新至2.58，任意经过CNCF(Cloud Native Computing Foundation，云原生计算基金会)认证的Kubernetes集群都可以部署Rancher的集群管理功能，使得Rancher能够兼容不同边缘云原生集群。

图5 k3s云边协同架构

轻量化、易于部署是k3s的优点，但是k3s对于Kubernetes的代码甚至基础实现机制的修改，使得k3s后续是否能够跟随上游Kubernetes发展，成为一个值得讨论的问题。同时，在测试中，k3s的资源消耗情况相对于KubeEdge并没有什么优势[9]，这些仍需要k3s进行持续的优化和改进。

3.4 Virtual Kubelet

Virtual Kubelet是一个开源的Kubernetes kubelet实现，它伪装为一个kubelet，可以使Kubernetes节点由其它Provider支持[10]。典型的kubelet实现每个Node节点上的Pod和容器操作，而Virtual Kubelet把其自身注册为一个Node节点，支持的功能有Pod增删、容器日志管理、Pod状态查询等，使开发者可以使用其自身的API部署Pod或者容器(如图6所示)。目前，阿里云、亚马逊、微软、腾讯云等多家云计算提供商开源了Provider，同时Virtual Kubelet支持自定义Provider。

图6 Virtual Kubelet示意图

Virtual Kubelet为多云互联提供了新的解决思路。Kubernetes集群中不仅可以将集群内的物理机或者虚拟机作为节点，借助Virtual Kubelet，Kubernetes API可以拓展到其它无服务器平台，得到其它服务平台的支持。因此，在多云场景中，不同的云可以开放自己的能力，提供自己的Provider，集群之间可以借助Virtual Kubelet互相调度平台能力，实现跨云的服务编排。Virtual Kubelet具有很好的拓展性，可以在公有云、私有云和混合云场景下实现。

Virtual Kubelet适用于边缘计算场景。在分布式部署架构中，中心云集中了较多资源，边缘云的资源量通常较少。而边缘云具备数量多、分布广的特点，终端设备通过接入边缘云获取服务。在边缘云资源有限的情况下，资源调度十分重要。当边缘云资源紧张时，可以将应用临时部署于资源丰富的云商。边缘Kubernetes集群部署Virtual Kubelet，通过Virtual Kubelet对接云计算提供商，借助云计算提供商弹性能力轻松应对突发业务流量。目前已有云计算提供商提供类似的服务，如阿里云ECI(Elastic Container Instance，弹性容器实例)提供安全的Serverless容器运行服务。用户无需管理底层服务器，也无需关心运行过程中的容量规划，只需要提供打包好的Docker镜像，即可运行容器，并仅为容器实际运行消耗的资源付费。阿里云ack-virtual-node组件，基于社区开源项目Virtual Kubelet，扩展了对Aliyun Provider的支持，并做了大量优化，实现Kubernetes与ECI的无缝连接。

4 运营商发展边缘计算的建议

电信行业也在进行云计算的演进，云原生的理念和技术体系被应用于网络功能和运营支撑系统，运营商在边缘云建设中也有一定的探索和成果。中国移动已完成制定容器层技术规范并在CDN边缘云试点中进行验证；中国电信自研MEC平台已经在智能制造、云视频直播等一系列toB、toC领域获得了广泛部署；中国联通自研MEC平台，在全国多省市开展MEC边缘云试点。

电信行业云原生演进逐渐深入，运营商的边缘云建设迎来新的机遇和挑战。结合目前云原生边缘计算的现状，运营商可以得到如下启示。

1)推进电信行业云原生边缘计算标准化研究。电信网络云原生的标准尚不完善，在边缘计算领域更有硬件异构、资源分散、组网形态差异大等诸多区别于传统云计算的特性，循序渐进推进电信行业云原生边缘计算标准化研究，使边缘计算场景的网络建设进一步规范。

2)推进电信行业生态开放。网络云原生是IT(Information Technology，信息技术)与CT(Communication Technology，通信技术)进一步融合的产物，需要云计算提供商、运营商、通信设备商共同参与，积极贡献开源项目，丰富边缘计算服务，打造开放的行业生态。

3)加快自身开发模式转型。传统的瀑布式开发不再满足云原生背景下的开发需求，边缘计算更需要提高灵活性和拓展性。运营商数字化转型中，要以DevOps、持续交付为依托，实现敏捷开发，保障边缘场景下全流程自动化。