云原生边缘计算：探索与展望
云原生计算是一种以微服务、容器化、软件定义网络和网络功能虚拟化为核心的新型计算范式，旨在通过轻量化和透明化的方式优化资源管控、提升动态弹性，解决传统云数据中心的高异构、不规则性和动态变化等问题。在边缘计算中，云原生技术通过容器分层特性优化低开销微服务部署，结合软件定义网络与网络功能虚拟化，实现算网协同，提升资源利用率和应用开发效率。云原生的高异构性和透明性使其成为边缘计算的理想解决方案，但其面临的挑战包括高分布异构资源管理、分布式服务状态管理、边缘智能应用以及安全隐私问题。云原生的高效性和透明性为边缘计算提供了新方向，未来研究需聚焦于如何结合云原生特性优化边缘计算的智能化和安全性。
摘要:
云原生计算基于低开销容器化的运行方式与边缘计算高度契合，鉴于此，建议将云原生技术应用于边缘计算领域，充分发挥其优势，实现对应用开发部署的透明管控。鉴于云计算与边缘计算在资源分布、异构性以及碎片化特征上的显著差异，边缘计算需要建立资源协同管控机制。基于云原生技术的发展现状，整合软件定义网络与网络功能虚拟化等前沿技术，构建全栈式云原生边缘计算架构。在此架构下，结合容器的层次化部署特性，设计适用于有限边缘计算资源的低开销容器部署策略，并深入分析云原生边缘计算所面临的关键挑战。
关键词：云原生 ; 边缘计算 ; 容器 ; 微服务
1 引言
面对终端数量激增导致的算力需求急剧上升，通过优化计算卸载策略等方法，可以充分挖掘云计算的算力资源。该方法已被广泛应用于多个领域，展现出显著的应用价值。然而，端到云之间的通信时延问题难以满足实时应用对低时延的硬性要求，因此边缘计算应运而生。边缘计算通过将计算资源部署在靠近用户端的边缘节点，利用网络边缘的计算能力来承载云服务，其"数据上行、计算下行"的模式突破了传统"终端+数据中心"的架构限制，从而满足了对时延和带宽的需求。该技术凭借其低时延、高带宽的特点，在物联网、5G、大数据、人工智能等多个领域发挥着关键作用，被视为未来计算技术的重要方向之一。特别是在6G技术逐步普及的背景下，通过构建边-端融合系统，结合算网融合调度技术，可以充分发挥6G超低时延的优势，这被认为是未来计算发展的新趋势。此外，与边缘计算相关的概念和技术创新，如计算优先网络、算力网络、多接入边缘计算等，凸显了边缘计算在 next-gen 网络和计算架构中的战略地位，引发了各行业对这一技术的关注与探索。
就当前产业环境而言，阻碍边缘计算发展的主要障碍之一是边缘服务的开发、管控以及边缘应用生态的构建。尽管边缘计算资源管理与任务调度优化已获得广泛研究，但目前业界尚未形成一套统一标准的资源管理与任务管理框架。尽管边缘计算在架构上与云计算具有高度相似性，但由于设备类型和性能存在显著差异、设备分布范围广且网络接入方式多样化、边缘设备处理的终端设备和需求类型多样的特点，传统云计算解决方案（如 OpenStack）在应用于边缘计算场景时存在诸多不适应性与局限性，具体表现在以下几个方面：首先，系统复杂性较高，由于边缘设备能力差异大、网络接入方式多样化以及多样的终端设备和需求类型，导致系统整体复杂度显著增加；其次，系统运行具有高度的不确定性，由于终端设备的移动性以及任务需求随时间和环境变化的特性，使得系统运行预测难度较大；第三，系统运行效率存在明显波动，由于边缘设备资源的异构性以及任务负载的动态变化特性，导致服务响应效率和系统稳定性难以保持恒定；第四，系统动态调整能力不足，由于云数据中心按需提供数据和服务的特性，使得边缘计算系统的动态适应能力相对较低。基于以上分析可知，开发一套专门针对边缘计算平台的'操作系统'势在必行。
尽管云计算与边缘计算的发展路径存在差异，但云计算为边缘计算提供了重要的参考与借鉴价值。在边缘计算领域，人们已开始将云计算相关技术框架与方法迁移至边缘计算环境，并根据边缘计算的特殊需求对其进行针对性优化。例如，针对边缘计算中资源分布广的特性，对OpenStack系统进行了定制化优化。近年来，云原生技术逐渐成为云计算发展的主流方向。以Kubernetes为代表的云原生物编排系统因其 container化、微服务化、松耦合化的特性，被广泛认可为分布式系统的核心操作系统。云原生通过基于服务的快速按需编排机制，满足了快速迭代与动态应用开发的需求，成为软件开发领域的主导力量。边缘计算作为云计算的重要延伸，其发展思路与云计算具有相似性。在硬件设计上，轻量级云原生技术（如 container）更适合边缘计算场景，因为这种技术能够实现用户间的资源隔离，从而有效支持资源的弹性伸缩管理以及应用的注册、发现、编排和发布流程，显著提升了应用开发的效率。然而，边缘计算的异构性使其在资源形态、网络接入和访问特征等方面均呈现多样性，这对应用开发人员提出了更高的管理要求，同时也带来了更低的运行效率。通过 container 技术实现资源抽象管理，使应用开发人员能够透明化地掌握资源控制状态，这种设计思路具有重要的理论价值与实践意义。基于此，将云原生技术拓展至边缘计算平台已受到学术界和工业界的广泛关注。目前，已有多项针对边缘计算环境的解决方案相继涌现，例如简化版的K3s框架以及华为技术有限公司开发的Kubernetes原生边缘计算平台KubeEdge，这些创新成果已获得了广泛认可。
云原生边缘计算通过容器等支撑技术，实现了底层物理计算资源的抽象与软化，从而实现了软件开发、运行维护与底层资源管控的分离。实际上，除了计算资源的管控，网络资源的管理同样不容忽视，这是边缘计算需要重点考虑的另一个关键问题。相较于云计算，边缘计算在网络异构性方面表现更为突出，主要体现在接入方式（有线与无线并存）、带宽异构、可靠性异构等多个维度。同时，边缘计算所具有的非规则网络拓扑结构，使其在资源管理方面呈现出独特性。作为移动互联网的重要支撑体系，边缘计算在技术发展日新月异的背景下，对资源管控能力提出了更高的要求。从网络运行机制的角度来看，邬江兴院士指出：在互联网多元化发展的背景下，当前僵化的网络运行机制会导致传输控制、资源管理、配置维护等多个环节的复杂性倍增，从而导致网络运行效率低下、用户体验不佳。针对这一挑战，以软件定义网络和网络功能虚拟化为代表的新一代网络技术，以开放网络为目标，打破了传统网络架构的刚性约束，为多端接入、个性化服务和创新应用发展提供了新的技术路径。通过实现网络层的软化处理，这种技术体系不仅实现了网络功能的开放化，还为定制化创新提供了技术支持，这种技术方案在云计算领域已得到了广泛认可与成功应用。
基于当前边缘计算的发展困境和云计算的前沿趋势，本文提出软化技术作为推动边缘计算发展的潜在思路。本文融合了云原生技术和未来网络技术，构建了全栈式云原生边缘计算架构，实现了算网融合的资源管控。针对边缘计算资源有限的特性，本文通过深入分析容器分层结构特征，研究了低开销的边缘服务部署优化方法。最后，本文对云原生边缘计算技术未来的发展挑战进行了展望。
2 云原生计算的发展现状与趋势
2.1 云原生架构：微服务和无服务器计算
云原生物网络通过灵活的资源调度机制，达成动态的资源配置，成为云计算开发与软件部署的高效方案，获得行业广泛认可。云原生物基金会定义云原生物的特征属性为：面向微服务、采用容器化封装和实现自动化管理。在云原生架构中，应用被构建为无状态且解耦度低的微服务，从而提升了服务的复用性和可靠性。采用云原生方式进行应用维护具有显著优势，能够适应DevOps模式和持续集成等研发需求。例如，当一个服务实例失效时，系统能够迅速生成备用实例并立即接管其功能；在服务请求波动较大时，系统能够灵活调整服务实例数量，优化资源利用率，确保服务质量。接下来，将详细介绍云原生计算的架构与支撑技术。目前，云原生计算主要分为微服务架构和无服务器计算架构两种主流模式。
微服务通过拆解一个大型单体应用为多个小型模块进行部署，这种技术方式具有显著特点，即支持快速构建、测试和部署单个服务，且不会对整个产品体系或其它服务造成负面影响。微服务体系实现了高效的发布机制，允许开发者首先向特定用户群体发布新特性，待该特性达到预期效果后，再向整个用户群全面发布。微服务体系具备卓越的敏捷性、稳定性和扩展性，这三项特性完美契合了应用开发、运行维护的全方位需求。
无服务器计算是通过提炼底层基础设施概念而形成的计算模式，这种架构设计使得开发人员能够专注于构建高效的应用程序，无需直接面对硬件服务器的可伸缩性、可用性和安全性问题。从应用使用视角出发，程序应最大限度地利用网络资源和存储空间，以确保当程序处于闲置状态时，硬件资源不会被浪费；而当系统负载激增时，计算架构能够实现弹性扩展，从而在任何程度上提升系统性能，而无需进行手动服务器添加操作。
微服务体系结构支持小团队的开发人员专注于单独的服务，每个团队负责执行特定任务。而无服务器计算通过这种方式，团队能够以最少的精力启动和运行微服务。微服务仍涉及一定量的计算资源集群管理，而无服务器计算使得应用开发者可以专注于代码编写并定义应该触发代码执行的事件，并将其留给云来处理其余的事。
2.2 云原生支撑技术
实现云原生需要开发者设计新的协议和架构体系，其中一些成熟的技术如容器技术、微服务调度工具（如Kubernetes）、服务网格等，为云原生的实现提供了丰富的技术支持和实践经验。云原生的关键支撑技术如下所述。
- 容器
本质上，容器是一个进程。通过实施进程隔离和资源管控，容器在运行过程中能够确保各进程之间相互独立运行。此外，容器具有卓越的移植能力，在多款主流操作系统上均能稳定运行。与虚拟机相比，容器在资源利用和部署效率上具有显著优势。其系统运行开销显著较高，且在程序移植和部署方面存在诸多不便。相比之下，容器具有极高的轻量化性能，打包和下载操作更加便捷。其中，Docker（开源）作为最为人熟知的开源容器引擎，为开发者提供了一种高效的方式，即通过构建包含应用及其依赖项的轻量级、可移植容器，实现快速部署到各类流行操作系统。在运行过程中，Docker的系统开销几乎可以忽略不计，其核心优势在于资源占用极低且部署速度极快。每个应用均可独立打包成一个Docker镜像，无需依赖其他应用或生产环境基础设施。这种设计使得Docker在研发、测试和生产环境中都能提供一致的运行环境。Docker采用客户端-服务器模式，通过远程应用程序接口（API）实现容器的管理和部署。Docker镜像类似于容器的模板，每次创建新容器时，均需基于现有的镜像构建。
- 容器管理器
单纯依赖容器难以满足开发者的需求。在集群中，通常会存在大量（约上万个）容器镜像，为了实现对这些容器的有效管理，如控制容器的生命周期、进行容器迁移，以及对容器间流量进行调度等，开发者需要一套完善的治理方案。目前，Kubernetes已成为广泛应用于容器治理的主流框架。 Kubernetes 简称 K8s，它是一个具有高度可移植性和扩展性的开源平台，专为管理基于容器的微服务架构而设计。在 Kubernetes 中，可以通过创建多个 pod（Kubernetes 的基本单元）来承载多个容器。每个 pod 可以同时部署多个容器，而每个容器则可以运行一个服务。通过内置或自定义的负载均衡策略，Kubernetes 实现了对一组微服务的管理、注册和访问功能。开发者可以通过 Kubernetes 的 kubectl 组件对这些服务进行有效的管控。
- 服务网格
虽然在多数情况下，Kubernetes能够实现微服务治理功能，但开发者在实际应用中仍会遇到诸多挑战。基于实际生产环境的特点，由于微服务的实现模式各有不同，若要实现微服务间的有效通信，开发者需要预先协调好通信接口和方式。另一方面，流量的管控与调度工作因需要综合考虑环境中的多种因素，因此开发过程往往较为复杂。因而，服务网格应运而生。Kubernetes与服务网格的对比如图1所示，作为服务间通信的基础设施，服务网格能够将微服务中的通用功能进行分离，例如服务注册与发现、负载均衡、熔断降级、流量管理、监控等功能。这些分离出来的能力极大弥补了Kubernetes在某些方面的不足。
图1 Kubernetes与服务网格对比
在服务网格架构中，每个微服务借助边车实现与其他服务间的通信，从而导致众多微服务与对应的边车呈现出网格状的结构，这正是服务网格命名的依据。服务网格能够在多种环境中运行，其中Kubernetes是其最常用的应用平台。服务网格（如Istio框架）与Kubernetes具有良好的兼容性，Kubernetes负责对应用进行生命周期管理，而服务网格则负责管理应用间的流量、安全以及可观察性。
云原生支撑技术框架如同图2所示，Kubernetes的Kube-proxy组件负责实现流量在Kubernetes服务中多个pod实例间的负载均衡。然而，Kube-proxy的配置是全局性的，无法对单个pod进行精细的管理。相比之下，服务网格将Kubernetes中的该功能分离出来，部署在边缘计算设备中，不再依赖Kubernetes的Kube-proxy组件，而是通过更接近微服务应用层的部署来管理服务间的通信、流量管理、负载均衡和可观察性。总体而言，Kubernetes通过Docker容器技术实现微服务的自动部署、重启、复制和扩展等功能。而服务网格则部署在Kubernetes上，负责提供应用间更灵活的流量控制、安全管理和可观察性。
图2 云原生支撑技术框架对比
- Unikernel
Unikernel是一种独特的、基于单一地址空间的机器镜像，它实现了底层硬件资源的直接获取，无需面对不必要的硬件抽象。Docker则是一种高效的容器化技术，专为解决应用移植性问题而设计。与虚拟机相比，Docker的镜像体积更小，但仍然达到数百兆。而Unikernel进一步缩小了体积，仅需几十兆甚至更低。在架构设计上，Unikernel去除了传统的操作系统，使应用直接运行在虚拟化平台或硬件上。由于其不包含不必要的软件包和依赖项，资源利用率得到显著提升。Unikernel的优势主要体现在三个方面：首先，其体积小巧，仅包含必要的依赖项和软件包；其次，启动速度极快，中央处理器（CPU）能够高效运行，通常启动时间仅需20毫秒甚至更低；最后，Unikernel被视为实现云原生技术的重要支撑，为分布式系统提供了坚实的基础。
2.3 云原生边缘计算
云原生技术推动边缘计算的发展，获得了业内的广泛认可，并开发出了多个具有广泛应用的框架，如阿里云近期推出的Openyurt开源项目。该框架以原生Kubernetes为基础构建，允许用户在边缘环境中进行微服务的管理和运行。它通过解决一系列边缘场景的挑战，包括如何减少设备与工作负载之间的长途网络流量、如何提升边缘环境的可靠性、如何实施安全验证、以及如何降低数据传输时延等问题，显著提升了边缘计算的效率和实用性。该框架不仅具备完全的Kubernetes API兼容性，支持Kubernetes的所有功能特性，还提供了一种独特的解决方案，能够将本机的Kubernetes服务转换为边缘运行状态，同时增强了集群在边缘环境中的稳定性。
KubeEdge 是云原生在边缘计算中延伸的典型架构，基于Kubernetes架构，它为边缘计算提供了多种功能支持，包括离线运行和边云协同功能。该架构分为云端组件和边缘组件，其中云端组件负责通过Kubectl CLI工具对目标对象的预期状态进行调度，而边缘组件则遵循“简单至上”的设计原则，有效降低了资源占用、故障率和维护难度。
在边缘计算领域，K3s被视为一种经典的解决方案。传统的Kubernetes架构因其组件繁杂而难以在边缘设备上高效运行。相比之下，K3s通过单一二进制文件实现打包与部署，安装过程快捷且易于操作。同时，K3s去除了那些对最低限度集群运行不必要的组件，补充了必要的功能模块，使其能够适应边缘计算的需求。
尽管目前已有若干架构可为开发者应对边缘场景提供支持，但这些架构仍存在局限性，它们往往仅聚焦于部分边缘环境要素，例如主要关注服务治理，而未充分考虑网络协议的融合，这在一定程度上限制了其应用效果。鉴于此，本文将在此基础上进一步整合服务网格、软件定义网络以及网络功能虚拟化等技术，构建一个全栈式的架构。
3 全栈式云原生边缘计算架构
云原生计算彻底改变了应用开发与运维模式，通过抽象和软化底层物理计算资源，应用开发运行维护人员将主要精力集中在关注应用自身，无需考虑底层物理资源。针对传统网络架构刚性基线技术在灵活管控方面的局限以及对网络资源与计算资源协同调度的制约，未来网络技术（如软件定义网络与网络功能虚拟化）提供了新的解决方案。结合云原生计算与未来网络技术，本文提出了一种面向边缘计算的全栈式云原生计算架构，实现了边缘网络资源与计算资源的协同管理。如图3所示，该架构的全栈式云原生边缘计算架构图。当前分布式计算系统结构的发展趋势是数据层与控制层的分离，如软件定义网络通过解耦数据层与控制层，并集中控制层面，极大地提升了计算机网络的灵活性和可定制性。服务网格则为控制器管理边车所代理的服务流量。因此，本文认为，数据层与控制层的分离是未来分布式系统架构发展的重要趋势之一。图3中所提出的架构体系最上层为控制层，包含面向多个功能组件的控制器，控制层的各个控制器组件负责管理其下各层的不同组件。
图3 全栈式云原生边缘计算架构
- 物理层
物理层是整个系统的基础层，包含多种边缘计算物理资源，如计算机、网络设备、通信设备、传感设备、存储设备等。从资源类型来看，边缘计算与云计算数据中心在架构上有相似之处。但从资源特性来看，两者存在显著差异，主要体现在高异构性和广布散性两个方面。云计算数据中心通常由单一主体运营，其物理设备架构相对统一。相比之下，边缘计算由于接入门槛较低，各类主体均可提供基础物理设施接入边缘计算平台。例如，移动运营商等主体可通过靠近蜂窝网络基础设施的计算设备接入边缘计算，提供物理资源。在基础设施提供商层面，物理资源的多样性不仅体现在容量上，架构上也存在显著差异。例如，计算机可能基于x86架构，也可能采用ARM架构，并可部署不同硬件加速器如GPU、FPGA等。此外，边缘计算靠近终端用户，其网络接入方式多样，不仅支持有线网络接入，还提供无线网络接入（如4G、5G、Wi-Fi等）。这种多元化资源供给导致了高异构性特征的出现，并使物理资源分布呈现广散性。因此，边缘计算在网络拓扑结构上与云计算数据中心存在显著差异，云计算数据中心通常采用规则的网络拓扑如FatTree、Bcube等，而边缘计算的网络拓扑因物理资源的地理分布而呈现非规则属性。这种高异构与广布散的特征对物理资源的管控带来了巨大挑战，阻碍了边缘计算的发展。通过抽象分析广布散的异构物理资源特征，我们发现这正是推动边缘计算发展的关键因素。
- 网络层
由于物理层资源的广布的特征，使得网络成为串联各类异构资源的核心。如前所述，传统封闭刚性的网络技术阻碍了边缘计算应用的开放性发展。因此，在本文提出的全栈式网络架构中，为实现算网协同的资源调度，单独抽象一层独立的网络层。网络层不仅包括交换机、路由器等基础通信物理设施，还包括驱动软件定义网络功能实现的各类基础软件（如Open vSwitch等）以及各类虚拟网络功能。通过将控制平面从数据平面中分离，使开发者无需改变硬件设备就能进行网络管理，从而实现对上层应用间的开放性流量管理与个性化定制。同时，网络功能虚拟化技术为应用间的流量管理提供了各类网络服务。通过软化传统基于硬件实现的虚拟网络功能，使网络设备功能不再受限于专用硬件，从而实现了对各类网络服务的灵活管理、新业务的快速开发与部署。
- 服务层
服务层直接采用云原生计算架构，其核心是在物理计算资源上抽象出各种服务构建边缘应用。因此，服务层同时涉及容器与虚拟机两种虚拟化技术。首先，与云计算数据中心类似，以虚拟机的形式抽象物理计算资源，提升物理资源利用率。在虚拟机中，可进一步地部署容器用于服务实例的实现与部署。通常情况下，一个容器不能满足一个微服务的所有需求，因此主流的容器管理器（如Kubernetes）会将一些容器联合起来，将其称为pod，并将pod作为最基础的处理单元，即服务实例。此外，在边缘计算场景中，由于资源限制，并非所有计算设备都适合部署虚拟机进行物理资源共享。因此，pod 及其所包含的各类容器也可以直接部署在物理服务器上。无论pod部署在虚拟机上还是物理服务器上，均对应用的开发与运行维护透明。也就是说，边缘应用开发运行维护人员的关注对象为pod或由pod提供的基础服务，不需要关注物理资源的管控，后者由边缘设施提供商进行运行维护。特别注意的是，在本文提出的全栈式架构中，引入了服务网格实现异构服务间的标准化流量通信管理。如前所述，每个服务将对应一个边车，边车与软件定义网络的数据平面融合，共同构成本文框架中的数据层部分。通过融合，使得网络层的软件定义交换机中的流表能够根据服务的属性信息（如服务名、端口号等）进行定制，如基于P4进行网络数据平面编程，而不需要仅按照传统软件定义网络中指定的属性信息进行网络流管控，加强网络管理的纵深与融合程度，从而通过全栈式的方式提供开放、灵活、可定制的网络流管理服务。
- 控制层
该控制层整合了多层级的管理组件，其中包括容器编排管理模块、服务网格控制器、软件定义网络控制器以及虚拟网络功能编排管理模块MANO。通过剥离控制层与服务层的交互，实现了边缘应用编排管理的全栈式、便捷且灵活的方式。容器编排管理模块基于应用需求、访问需求以及物理资源的动态变化，依据设定规则实现了服务注册、部署、扩容、销毁等全生命周期管理。其中，Kubernetes主节点组件可作为实现该功能的专用工具。与之协同运作的是服务网格管理器（如Istio Controller），该组件通过管理各服务对应设备中的网络流量，实现了服务间的负载均衡、安全监控、流量熔断等功能。软件定义控制器则通过南向接口（如OpenFlow）向软件定义交换机注入流表项，从而管控数据流在网络层中的行为。服务网格控制器与软件定义控制器相互配合，前者从服务层面进行逻辑管控，后者则对其进行了物理层面的实现。网络功能管理模块则与容器管理模块具有相似功能，但其管理对象为虚拟网络功能。控制层各模块的协同运作，使得网络功能的生命周期管理得以高效执行，这与分布式计算的发展趋势高度契合。
4 面向边缘计算的低开销微服务部署
云计算数据中心通常拥有丰富的资源，而边缘计算的资源容量相对匮乏。在将云原生技术应用于边缘计算时，资源消耗是一个不容忽视的关键考量。微服务部署是实现云原生应用的关键基础，而高效部署微服务对云原生边缘计算具有重要意义。云原生技术中的容器组件则为实现低开销微服务部署提供了新的优化方向。尽管边缘计算中的微服务部署优化研究已受到广泛关注，但现有研究通常将容器视为轻量级虚拟机，却往往忽视了其分层属性。因此，本节将深入探讨如何充分利用容器的分层特性以实现低开销的微服务部署优化。
4.1 容器分层与问题陈述
在实现过程中，容器被组织为分层结构，而非整体式设计。具体而言，当容器基于Ubuntu系统实现时，需要MySQL数据库作为支撑。其底层架构基于Ubuntu镜像，上层依次叠加MySQL数据库和所需功能模块。这种分层设计不仅有助于提升容器的扩展性，还能在一定程度上优化资源利用率。在实际应用中，层共享机制能够显著降低资源开销。具体而言，在镜像拉取过程中，层共享机制减少了冗余层的拉取，从而降低了网络带宽的使用和启动时间。同时，边缘服务器通过共享层结构，减少了不必要的存储空间，进一步优化了资源利用。
边缘计算环境中的分布式服务器存在资源有限性，同时需要部署的容器具有多样化的计算与存储资源需求。如何充分考虑容器的分层特性，实现边缘计算环境下的低开销容器部署，对推动云原生边缘计算具有重要意义。首先，构建分层敏感的低开销容器部署优化理论模型，为便于读者理解，对模型中涉及的数学符号及其定义进行了总结，数学符号及其定义如表1所示。
4.2 层共享敏感的低开销容器部署优化
本文考虑一个边缘计算环境中包含一个服务器集合
在以下，每台边缘服务器均配备有计算、存储和通信资源。这些服务器端设备
计算资源、存储资源和通信资源的容量分别用Pn、Sn和Bn表示。将被部署的容器集合用Cn表示。
，所有容器所包含的层表示为集合
。不同的层具有不同的大小，即存储空间要求不同。假设层
的大小为Cl。容器与层的关系可表示为
将容器与边缘服务器间的部署关系表示为二元变量，如式(2)所示。
由于已知容器所依赖的层结构，可以观察到容器的部署方式与边缘服务器之间存在密切的相互依赖关系。因此，可以定义二元变量
当且仅当容器i部署于边缘服务器n上时，所有相关层也需部署于该服务器n上，从而形成关系式
为满足部署的完整性要求，每一个容器均需要部署在一个服务器上，即
考虑部署在任何一台边缘服务器上的容器及各层存储资源配置方案均不能超过服务器的存储空间容量。存储空间容量限制可表示为：容器及各层存储资源配置方案均不能超过服务器的存储空间容量。
类似地，Pn为服务器
拥有的计算资源，容器
需要的计算资源为di，则计算资源容量限制可表示为
对于通信资源限制，Bn为边缘服务器
拥有的通信资源，bi为服务
的通信资源需求，则有
在综合考虑以上因素的基础上，可以将其建模为一个整数线性规划（ILP, integer linear programming）问题，如公式（9）所示。
ILP问题一般被归类为NP-hard 问题，常规求解方法面临计算规模呈指数增长的挑战。借助求解器Gurobi，可以有效获取最优解，但当部署环境复杂（如边缘设备数量多、容器数量多）时，求解效率会显著降低。鉴于此，本文在此基础上提出了一种基于ILP优化模型的贪心算法，以期在保证解的合理性的前提下，进一步提升求解效率。
式(9)所示优化理论模型由于存在整数变量导致计算复杂度增加，即二元变量x和y，通过线性松弛将其松弛为0到1之间的连续实数变量，可将其转化为线性规划问题（LP，Linear Programming）。LP问题可在多项式时间内求得其最优解，然而，线性松弛导致x和y的物理含义无法直接映射到目标部署关系上，因此，需要进一步将其还原为0或1，本文采用贪心算法进行还原。
如算法1所示，松弛算法通过以下步骤进行操作。首先，对原问题进行松弛处理，将x和y视为0到1的实数变量。此时，原问题被转化为一个线性规划问题，通过求解器，我们获得x和y的实数解。随后，将这些实数解进行二值化处理，用于指示容器应放置在哪个服务器上。在这一过程中，我们采用贪心策略对各服务器进行权重计算，该权重由两部分构成，其中一部分是解LP问题的结果，另一部分则由当前服务器的资源量决定，资源越多，权重占比越大。在算法1中，我们根据各服务器的权重值，对连续变量进行离散化处理，权重值越大，变量被赋值为1的可能性越高。当所有容器都被合理分配至相应服务器后，各服务所需的层结构也随之确定，此时我们即可计算出在每个服务器上需要部署的具体层集合。需要注意的是，由于离散化处理可能导致部分约束条件无法满足，因此需要不断重复这一过程，直至所有约束条件得到满足。最终，我们便能够获得所需的结果。
通过数值模拟实验，验证了本文所提出的算法的有效性。生成了10个服务器，其中每个服务器的计算资源Pn均匀分布在[10 000,12 000]区间内，存储资源Sn和通信资源Bn均匀分布在[2 000,3 000]区间内。部署了10个容器，其中层大小取自200到300的区间，每个容器的计算资源需求均匀分布在[1 000,2 500]区间内，通信资源需求均匀分布在[600,1 000]区间内。为了突出本文所提出层共享敏感的容器部署方案的优势，将传统不考虑层共享的方案与本文方法进行对比分析。对于层共享敏感的方案，分别得出了通过求解整数线性规划模型得到的最优解和基于本文提出的方法获得的次优解。实验结果表明，容器数量对部署开销的影响如图4所示，边缘服务器资源量对部署开销的影响如图5所示。
图4 容器数量对部署开销的影响
图5 边缘服务器资源量对部署开销的影响
图4重点分析了容器数量增加对部署开销（以存储占用率为衡量标准）的影响。通过图4可以看出，当容器数量逐渐增加时，三种算法所需的总存储空间也相应增加。对比分析发现，采用层共享机制的部署方案在资源利用率方面均优于不采用层共享的方案。此外，本文提出的松弛算法能够逼近最优解。从图4的示意图可知，当容器数量较小时，可共享的层数有限，导致规划空间受限，松弛算法仍能提供与最优解几乎相同的结果。然而，随着容器数量的增加，占用的空间也随之扩大，总消耗呈明显上升趋势。值得注意的是，采用层共享存储方式能够显著降低部署开销，这一优势随着容器数量的增加而愈发明显。这是因为，随着容器数量的提升，可共享的层数量也随之增加，层共享所带来的优势也随之扩大。
图5展示了服务器资源提升与其部署开销之间的关系。随着资源大小按倍数增加，存储空间、计算资源和通信资源的同步提升将导致单个服务器上可部署的容器数量也随之增加。随着资源规模的扩大，单个服务器上可部署的容器数量也会随之增加，从而使得这些容器能够共享更多的层级结构，最终降低总部署开销。即使采用无层共享的方案，其部署开销也难以超越层共享策略。实验结果表明，当存储空间、计算资源和通信资源达到一定水平时，所有容器均可集中部署至一个或少数几个服务器上。此时，松弛算法与最优解之间的性能表现完全一致。
5 展望与挑战
尽管云原生展现出推动边缘计算发展的巨大潜力，工业界已陆续开发出一系列解决方案，但该领域的研究仍处于起步阶段。边缘计算环境与云计算数据中心的本质差异导致云原生边缘计算面临诸多挑战，本节将深入探讨这些挑战。
- 广分布高异构资源管理
边缘计算资源分布于全球各地，涵盖用户终端设备、通信基站、智能路由器、边缘服务器等多个领域。云计算中的资源集中管理模式，使其管理架构和框架体系（如 OpenStack）不适于应对边缘计算中分散部署的资源管理需求。因此，亟需开发一套专门针对广分布、高异构边缘环境的资源管理解决方案。当前关于边缘计算资源的管控研究，主要集中在算法层面，往往忽视了在实际部署过程中的一些关键细节问题。此外，边缘计算系统面临的多维度挑战不容忽视，包括但不限于 CPU 架构的多样性（如 x86 与 ARM 处理器）、硬件加速器的共存配置（如 FPGA、GPU 等加速器）、以及无线与有线通信的混合部署等特性。这些复杂因素对边缘计算资源的管理带来了严峻挑战。尽管云原生技术使应用开发、运行和维护人员能够无需深入关注这些细节问题，但同时也对基础设施的管理者提出了新的要求，即需要设计出既能保证上层应用的透明性，又能在一定程度上感知上层应用特征变化的高效管理方案。
- 分布式服务状态管理
在云原生计算体系中，微服务或函数功能本身并不携带状态信息，但现实中并非所有服务或函数都完全缺乏状态管理，因此状态管理问题成为云原生计算体系中一个亟待解决的关键议题。在云原生边缘计算场景中，这一问题表现得尤为突出，主要源于前述边缘计算平台环境所具有的独特特征。此外，边缘计算服务的请求具有高度的动态性和时空异构性，这使得云原生边缘计算中的状态管理面临新的挑战。不言而喻，集中式的单一状态管理方案无法满足云原生边缘计算的需求，因此必须开发一套适用于分布式服务状态管理的先进方法。鉴于边缘计算环境的高动态性和时空异构性特点，服务会在短时间内完成快速部署、销毁和扩展操作，相应地，分布式服务状态的存储位置（包括一份或多份备份）、存储方式（如内存或硬盘）、同步机制（若存在多份备份状态）、更新策略（增量更新或全量更新）等都需要与服务生命周期管理进行有机衔接，从而实现对服务状态的有效管控。
- 边缘智能的应用
随着边缘计算技术的快速发展，边缘智能逐渐成为行业关注的焦点。尽管边缘智能主要指部署在边缘计算平台上的各类人工智能应用，但本文认为，边缘智能的一个重要应用场景是边缘计算平台本身。云计算数据中心需要一套自动化、智能化的运行维护方案，而广分布、高异构且资源供需动态性高的边缘计算平台对智能化运行维护的需求更为迫切。在拓扑非规则且资源高异构的边缘平台上，海量的微服务需要进行部署、扩容和缩容操作，同时伴随着服务请求的高度时空动态性。这些操作需要处理大量且维度丰富的数据，且对数据处理的时效性有较高要求。这些挑战与算力有限的边缘服务器之间的矛盾，可以通过云边端融合构建分布式边缘智能环境，并通过智能体协作来实现对云原生边缘计算运行时的智能管控，从而找到潜在的发展途径。在这一领域，包括强化学习（包括深度强化学习）、联邦学习、迁移学习等在内的多种技术都已展现出其潜在的应用价值。
- 云原生边缘应用安全与隐私
云原生的核心支撑技术是容器。相较于虚拟机而言，容器在隔离性方面存在明显不足。这种低隔离性不仅导致资源竞争，还带来安全与隐私风险。在云原生体系中，这种不足难以通过轻便性来弥补，两者难以兼得。因此，在多边缘计算设施提供商与多边缘服务提供商共存的云原生边缘计算环境中，保障边缘应用的安全与隐私已成为不可或缺的任务。本文主张，可信执行环境（TEE, trusted execution environment）是实现这一目标的潜在解决方案之一。目前，主流的CPU厂商已推出自家的TEE产品，例如Intel公司的SGX、ARM公司的TrustZone等。然而，TEE为了保障业务的安全保密执行，必须考虑一系列复杂因素。例如，SGX的安全内存空间存在容量限制，而TrustZone则要求CPU实现独占。如何将容器（包括安全容器与非安全容器）的编排调度与TEE的特性相融合，是一个亟待解决的关键问题。
6 结束语
云原生技术在云计算中的应用，为推动边缘计算的发展，开创了新的技术探索方向。本文首先简要阐述了云原生的核心概念及其关键技术要点，继而结合边缘计算的特定场景，巧妙地融入了软件定义网络与网络功能虚拟化技术，构建了一个全方位的云原生边缘计算架构。该架构通过实现控制层与服务层的抽象分离，实现了算网协同下的高效边缘资源管理与服务运行维护。进一步地，针对云原生技术的特性，本文深入研究了容器分层特性敏感的低开销部署优化方案，通过这一实例研究表明，云原生边缘计算中的资源管控必须充分考虑其特有的技术特征。最后，本文对云原生边缘计算的发展前景进行了展望。总体而言，云原生技术与边缘计算的契合度非常高，尽管这一新兴技术概念与方法论仍处于探索阶段，但随着研究的不断深入，未来必将展现出巨大的发展潜力，我们对此充满期待。