李铭轩 ，曹畅 ，唐雄燕，何涛，李建飞，刘秋妍

1.中国联通网络技术研究院，未来网络研究部，北京 100048

2.中国联通网络技术研究院，无线技术研究部，北京 100048

引 言

随着云计算技术的发展与企业上云的加速推进，基于云化架构构建企业基础设施平台已经成为业务普遍采用的方式。预计到2025年，85%的企业应用将会承载在云上[1]。同时电信运营商一直十分重视云计算市场和技术的发展，其内部IT 系统已经基本完成云化改造，正在推动其核心业务云化改造，并且纷纷成立专业云服务公司，开拓企业市场[2]。随着国家大力提倡发展新基建，云计算作为基础设施建设的重点领域将会得到快速的发展。

现有的云计算发展方向包括两个方面：一方面沿着传统的技术路线发展，采用资源集约化的方式着重建设大规模和超大规模数据中心，并且由数据中心统一提供IT 资源；另一方面的云计算发展路线则是着重研究面向异构云计算资源进行协同和纳管，其中多云管理目前是这种云计算技术发展方向的代表。而随着5G 技术的发展，边缘计算成为了信息技术领域和通信技术领域相互结合的热点。和传统的云计算发展路线不同，边缘计算主要研究如何更好地将外围或者边缘资源有效的进行管理，这就为边缘计算的研究提出了挑战。一方面，因为边缘资源更靠近用户侧，要求更低的用户访问时延；另一方面，边缘计算设备数量众多，而且存在计算架构差异性等问题，如何实现对海量的异构边缘计算资源的统一管理等也是一种挑战。另外，由于边缘计算节点分布比较广泛，计算节点之间的协同和资源的调度相比于传统的云计算对于网络的要求更高，因此边缘计算的研究除了传统的计算、存储等虚拟化技术的研究外，需要更加关注如何实现网络和边缘计算的协同，从传统的云网融合向算网融合的方向发展。

本文主要研究了基于算力网络如何实现对于边缘嵌入式计算资源，诸如ARM、GPU 等多种嵌入式设备进行资源纳管，从而能够解决算力网络下的异构计算资源协同管理问题。

1 算力网络

算力网络从传统云网融合的角度出发，结合边缘计算、网络云化以及智能控制的优势，通过网络连接实现更加广泛的算力资源的纳管和动态调度。但是，区别于传统的云计算资源的纳管采用集中式的资源管理或者集约化的资源提供，在算力网络的资源纳管中更多考虑了网络延时、网络损耗对于资源调度方面的影响。因此网络的核心价值是提高效率，算力网络的出现正是为了提高端、边、云三级计算的协同工作效率。算力网络整体技术架构如图1所示。

图1 算力网络技术架构Fig.1 Technology architecture on computing power network

依据上述算力网络架构，通过计算和网络的联动将云、边、端设备协同统一起来。其中中心云采用传统的云计算实现集中式的资源统一管理，在中心云中主要面向大规模或者超大规模的数据处理，以电信运营商为例，中心云主要承载面向全国的业务平台运营和数据处理[2]。在边缘云由于接入的边缘数据中心众多，而且分布比较广泛，基本上每一个边缘数据中心通常会采用相对独立的轻量化容器集群来实现，而在特殊行业或者指定场景下，行业用户拥有自己独立的数据中心或者业务上要求数据保密等场景下，也要求在用户环境下形成一个相对比较独立的云资源池[3]，同时在边缘云的统一管理中，需要将此部分单独作为独立的边缘云进行管理，同时在算力的分配或者应用的部署方面需要指定部署到用户的边缘云内，因此边缘云多数采用Kubernetes多集群的方式来实现多个边缘计算集群的协同管理。在算力网络设备端侧，结合现有工业互联网以及智慧城市等场景，往往涉及海量的前端嵌入式边缘设备，而且采用的计算架构有ARM、DSP、FPGA、SOC 等，负责用户的数据采集、用户侧的业务访问入口和交互等，因此通过算力网络将整个云、边、端的计算资源协同起来，采用分级、多集群的方式进行统一管理。目前在中心云主要采用OpenStack等传统的IaaS 进行承载[4]，而在边缘或者远端设备上的计算资源通过轻量级的云原生Kubernetes 等i-PaaS 和A-Paas 进行计算资源的管理和应用能力的管理等。

2 轻量级云原生架构

依据上述算力网络整体架构，在电信运营商的数据中心分级部署方案中，边缘数据中心或者边缘机房主要突出计算灵活、轻量化等特点，面向用户提供低延时的网络接入和应用访问，因此现有的边缘资源的算力调度方案主要采用基于云原生方式来实现的，面向用户提供业务平台的快速部署、业务访问，而其中资源调度和管理平台是以Kubernetes为主的容器云来实现资源调度编排和统一管理。依据参考文献[5]所描述，Kubernetes 主要采用主从模式来实现计算节点的统一管理，其总体技术架构如图2 所示[5]。

图2 Kubernetes 技术架构Fig.2 Technology architecture on Kubernetes

结合Kubernetes 技术架构主要采用主从模式，Master 节点主要负责资源的调度和键值数据库的存储，同时实现POD 的生命周期管理，同时Node 节点主要作为计算节点，实现本地Pod 的部署运行和本地相关计算、存储和网络资源的纳管。因此Kubernetes在开源之初，就定位为 i-PaaS 功能，既具备上层PaaS 平台的能力，同时又对底层IaaS 资源具备资源纳管的能力。随着近年来Kuberentes技术的飞速发展，目前Kuberentes 已经发展到了1.17 版本，不仅仅可以纳管通用CPU 等通用计算资源，同时也支持对于GPU、ARM 等专用计算资源的管理。

另一方面，由于通用型的嵌入式设备自身的计算、内存以及存储等方面的资源有限，从而导致Kubernetes 在进行部署时受到限制。现有的解决方案往往通过修改嵌入式设备的系统配置，诸如扩展SWAP 交换空间等方式以保证Kubernetes 能够顺利的安装[6]，参考文献[6]正是按照此种方式实现的。但是在实际设备运行过程中还是存在容器运行受限、集群本身数据库和相关组件运行占用较多资源等问题。针对这些问题在业界也越来越引起广泛的关注，目前在云原生开源社区最新开源项目K3S 针对原有Kubernetes 进行功能裁剪和优化，使其成为更加轻量化的容器云编排调度平台，能够更好的应用于面向边缘计算、物联网等场景下的多种嵌入式设备的部署和容器编排管理，因此项目一经发布在社区获得广泛关注，其技术架构如图3 所示。

和Kubernetes 技术架构相比，K3S 的技术架构同样是采用C/S 架构，并且在Server 主要通过KubeAPI 来实现和Kubernetes 中的API Server 相同的功能，通过KubeAPI 提供集中的连接，并且通过Controller Mananger 和Scheduler 来实现节点管理和资源调度管理等，这样外部系统在访问K3S 集群时，可以采用标准的Kubernetes 的接口进行访问，而不需要再单独开发一套独立的访问接口。不同点在于原有的Kubernetes 采用etcd 键值型数据库来实现数据管理，而在K3S 中为了满足轻量化的需求，改用SQLite 实现数据库管理。同时在底层容器引擎方面采用Containerd 来实现POD 管理。

图3 K3S 技术架构Fig.3 Technology architecture on K3S

在系统集成方面，由于整个云原生平台之间都是通过API 接口实现相互之间的访问和调用，而K3S 平台主要是由KubeAPI 提供外部访问接口，同时该接口是经过CNCF 认证的标准Kubernetes 接口，因此K3S 接口和标准的Kubernetes 的接口是一致的，可以实现无缝对接。基于K3S 技术架构设计的考虑一方面可以保证K3S 对外提供标准的Kubernetes 平台接口；另一方面，经过架构的精简和优化，使得K3S 本身的架构更加轻量化，整个的可执行性文件可以精简到几十兆，能够更加适用于在嵌入式系统等有限计算平台上进行部署。

3 边缘资源调度方案

根据参考文献[7]所描述的算力网络的四个特征要求，包括：资源抽象、业务保证、统一管控和弹性调度等方面，其中弹性调度能够实时检测业务流量，动态调整算力资源，完成各类任务高效处理和整合输出，并在满足业务需求的前提下实现资源的弹性伸缩，优化算力分配[7]。在算力网络资源调度方面，一方面采用轻量级的容器调度平台适配于开放式嵌入式边缘计算集群；另一方面，实现了统一的多集群的边缘计算集群的统一管控和动态扩缩容的资源弹性调度。结合现实情况，由于现有在边缘侧的设备资源中存在大量的嵌入式等工控设备等，因自身的计算资源和存储资源有限，传统的Kubernetes 云原生架构无法承载，因此本文在面向算力网络的边缘资源调度方案设计过程中，考虑采用“Kubernetes+K3S”的分级云原生容器资源调度方案，前端嵌入式设备基于K3S 实现资源管理，基于Kubernetes 来实现云原生多集群的统一管理。

3.1 边缘系统整体架构

在面向算力网络Kubernetes 多集群计算资源管理方面，本文采用基于“Kubernetes+K3S”两级联动的架构来实现统一的边缘侧资源调度管理，即边缘计算节点侧采用传统Kubernetes 云原生实现边缘计算节点侧的资源纳管，同时负责底层嵌入式终端集群的注册和管理等统一多集群调度管理，而前端嵌入式终端集群则采用更加轻量级的K3S 云原生平台实现资源管理，其总体的技术架构如图4 所示。

图4 边缘系统技术架构Fig.4 Technology architecture on edge system

依据上述系统技术架构，在面向整个边缘系统的资源调度方面主要是基于云原生容器化的方式来实现。以电信运营商为例，现有边缘侧的基础设施部署情况，边缘云主要分布在省分地市级边缘机房或者用户的数据中心内，主要采用通用型服务器作为计算节点，硬件性能相对较高，同时可以支持GPU、FPGA 等多种加速硬件资源，因此集中部署云原生的Kubernetes 容器集群，甚至有些边缘云部署轻量级的OpenStack 云计算集群，比如目前著名的边缘计算解决方案StarlingX，而前端设备则主要连接海量的嵌入式设备，负责数据采集、工业控制以及用户交互访问等。目前市场上的嵌入式设备主要基于“MCU+协处理器”的SOC 架构来实现，其中MCU 目前普遍采用ARM 架构的处理器实现设备的管理和连接，而协处理器则面向不同的数据处理类型采用不同的专用芯片，比如GPU 主要面向二维数据的图像处理和视频处理，NPU 主要面向张量数据的处理等。本文基于轻量级的K3S 实现容器化的嵌入式设备资源调度，应用程序将根据策略以POD 的形式调度到指定的嵌入式设备上运行，同时前端接入的传感器设备或者工控设备等通过MQTT、HTTP和GRPC 等通信协议将采集到的数据上传到嵌入式设备上进行处理，或者将嵌入式设备发送的指令传递到前端设备上执行[8]。

3.2 基于ARM 的容器部署

本文主要采用K3S 的ARM 部署方式，根据参考文献[9]所描述的部署需求，目前的K3S 版本支持硬件最低要求仅需要1 个CPU、512M 内存，同时面向X86_64、Arm64 和Armv7 等平台发布，因此基本上涵盖目前市场上绝大部分ARM 平台架构[9]，另外K3S 包含了轻量级的容器引擎Containerd，并不需要额外安装Docker 引擎，在底层容器引擎方面K3S 可以默认采用Containerd 的容器调度方式，但是也支持通过Docker 方式来实现容器调度。在整个嵌入式设备的容器部署和调度方式上，如图5 所示。

图5 边缘设备容器部署和调用方式Fig.5 Edge device container deployment, invocation method

依据容器化部署方式，结合具体的应用场景需要，在部署K3S 的Agent 节点时，可以选择K3S 默认的Containerd 作为底层的容器调度引擎，也可以选择Docker Engine 作为其容器调度引擎，但是需要在部署K3S Agent 之前就已经成功安装了Docker Engine，目前Docker Engine 官方也提供面向诸如ARMv7 架构的版本。根据官网安装部署文档所描述的具体操作，只需要在安装部署K3S Agent 时通过参数INSTALL_K3S_EXEC=”docker”传递给K3S系统，以表明在后续的容器调度过程中使用Docker Engine 作为容器调度引擎。但是需要说明的是，由于K3S 架构采用C/S 主从方式，在Agent 节点的部署过程中可以选择容器引擎，而在Server 节点上只能采用Containerd 作为其唯一的容器调度引擎。因为在整个K3S 的POD 运行管理过程中，K3S Agent是作为唯一的POD 运行和调度的载体，而Server 只是负责整个K3S 集群的运行管理，因此不需要额外地执行相关的容器运行等，通过这种方式可以大大提高K3S Server 的轻量化，也可以实现Server 和Agent 可在同一个节点上进行部署。另外，在嵌入式集群中具有控制节点，相比于其他MEC 方案诸如Kubeedge 等，集群具有自主可控的资源调度能力，这样更适合未来基于神经网络的算力网络智能化发展。

3.3 基于专用芯片的容器部署

面向专用芯片的边缘嵌入式设备一般在特定场景下对于数据处理有特殊要求，在芯片的架构设计上主要采用“MCU+专用芯片”的SOC 方式进行构建，通常采用ARM 作为MCU（主控单元），具体负责整个设备的系统管理、外部通信以及访问，而专用芯片则包括诸如GPU、NPU 以及FPGA 等，专门负责数据的处理和相关算法的硬加速处理等功能，而在MCU 和专用芯片之间往往通过专用的数据通道进行数据传输，比如HDI、HCI、SPI 等，各厂家设计的芯片不同，可能采用的数据传输协议也各有不同，而对外的数据输入和数据输出则主要由MCU 负责。由于专用芯片在某些特定场景下对于数据的处理具有较高的处理能力，因此和通用性处理器相比，专用芯片在算法训练、推理和硬件编解码等方面具有非常明显的优势，因此在边缘计算场景下，开始逐渐采用专用芯片来执行算力。目前在容器化部署方案上，各厂商都结合自家的专用芯片推出了相应的解决方案，通常的技术架构则是基于MCU 的嵌入式操作系统提供驱动层或者系统适配层，用于专用芯片的资源访问接口和资源调度能力，并通过插件方式实现Kubernetes 对于专用芯片资源的调度和适配。本文以英伟达的嵌入式开发板Nvidia Jetson Nano 为例具体阐述面向专用芯片的K3S 部署方案和调度过程，英伟达在嵌入式系统推出了基于GPU 的驱动层，并且在原生Docker 引擎的基础上推出了自己的容器编排调度工具Nvidia-docker，并且该容器引擎和英伟达的GPU 开放平台CUDA 进行了完美的适配[10]，因此在容器部署过程中主要基于英伟达的Nvidiadocker 进行容器调度，并且通过驱动来为POD 分配具体的GPU 资源，其具体的架构如图6 所示。

图6 GPU 容器部署方式Fig.6 GPU container deployment on GPU

依据GPU 容器部署方式，在算力资源调度过程中，可以通过在K3S 集群的配置文件yaml 中创建资源对象Resource，并且通过配置GPU 的数据量来指令K3S 集群为该POD 分配GPU 资源以执行相应的算力，而该参数配置会通过Nvidia-docker 来调用底层的驱动在创建POD 过程中为其提供指定的GPU数量。

而在上层的POD 调度和配置方面，通过上述容器化部署以及POD 资源分配方式，可以在标准的Kubernetes 配置文件yaml 中创建Resource 对象[11]，并且在该资源对象中设置计算单元数量，而该资源对象下的计算单元类型可以进行扩展和定义，因此为后续的其他专用芯片的资源调度和管理提供了可能。用户可以在配置文件中为POD 指定不同的专用芯片来运行。

3.4 基于标签的算力调度机制

在面向算力网络的边缘资源调度机制方面，由于考虑需要将整个边缘侧和前端嵌入式设备侧的算力资源统一调度和纳管。在算力应用匹配和算力节点调度方面，基于Kubernetes 提供的标签以及容器标签来实现整个边缘侧的算力调度机制，通过为前端嵌入式设备在注册到K3S 集群时，为设备创建节点标签，同时在创建POD 时可以通过节点标签将POD 部署到指定的边缘节点上运行，其调度流程如图7 所示。

基于标签的算力资源调度机制主要是基于Kubernetes 的Scheduler 和Controller manager 来实现的。首先在创建K3S 集群时，为算力节点统一进行命令规则，而算力节点的标签命名统一由设备管理模块进行管理，并且维护整个集群中设备节点的基本信息。在创建容器时根据应用场景和用户需求的不同，通过在设备管理模块中查询匹配的计算节点，并且在创建容器的配置文件中进行指定，从而使得资源调度平台为容器应用分配合适的计算节点。

4 应用场景

目前业界正在积极探索算力网络和工业互联网以及物联网等行业的实际落地场景，以智能驾驶业务场景下的算力网络资源调度为例，车载系统一方面在保证低时延的数据处理需求的情况下，需要将数据和控制尽可能的保证在本地进行处理，同时需要通过MEC 等实现云端资源和策略调度等协同智能路灯等信号的处理和反馈；另一方面，由于车载系统本身的计算和存储能力有限，因此需要基于正如本文所述的K3S 等轻量级的资源调度系统来实现车载系统的资源管理和应用运行。具体如图8 所示。

图7 基于标签的算力资源调度Fig.7 Computing power resource scheduling based on label

图8 面向智能驾驶的算力网络资源调度Fig.8 Resource scheduling of computing power network for intelligent driving

基于上述智能驾驶应用场景下的算力网络资源调度，通过环境感知来实现周围智能设备的数据采集和智能训练以实现无人驾驶车辆自主识别障碍物，通过避障规划来实现判断障碍物后所采取的措施，并且跟踪障碍物并及时做出判断和措施。上述流程强调智能驾驶车辆自主的学习处理能力以及及时和中心业务平台的联动时延要求，运营商目前积极推动“5G+MEC”实现智能驾驶的解决方案以实现低时延和资源轻量化调度，从而拉动包括智能驾驶、智能灯杆、智能交通控制等智慧城市公共交通的整体协同和资源管理。

5 结论和展望

随着算力网络技术的发展，将广泛的边缘计算节点纳入到统一的资源管理，尤其是在算力网络中引入嵌入式设备管理和自主资源调度机制，改变了传统的嵌入式设备只能被动接受服务器指令和上传数据采集等工作模式，使得嵌入式设备集群更具自适应能力，为后续AI 算力以及神经网路架构下的深度学习分层在嵌入式设备集群上的部署和运行，以及嵌入式设备的自主学习能力和智能交互提供了可能。随着未来具备AI 能力的专用芯片的发展和普及，算力网络除了在数据中心和边缘数据中心实现资源的纳管外，对于嵌入式设备的自主学习能力和自适应能力会提出更高的要求。通过本文所提出的面向算力网络的边缘资源调度解决方案的研究，可以更好的实现算力网络应用于边缘计算、物联网、车联网等应用场景下的统一资源调度以及智能化的运行模式。

利益冲突声明

所有作者声明不存在利益冲突关系。