边缘计算框架_基于云原生的边缘计算开源框架研究

本文作者：中国联通智网创新中心云边协同小组：常乐/栗霖/赵斌/隗英英

随着5G的到来，边缘应用的数据量和终端的数量迅速增长。根据IDC预测，到2023年，全球联网设备将会达到489亿，大部分数据都在终端形成、积累，传送到云端，进行数据处理，再返回到终端指导业务。这一系列动作将对网络带宽产生数百Gbps每秒的超高需求，不仅会存在延迟，还需要面临弱网卡顿、连接成功率低等诸多问题，用户体验无法保障。因此需要将算力从中心迁移至边缘，减少中心网络及算力压力。

当计算迁移至边缘，就需要云网边端相互协同，保证业务的展开。在云网边端协同架构的业务中，边缘侧，计算能力可下沉部署到边缘进行业务部分处理；中心云进行业务统一管控。在本地进行数据的初步分析和处理，承担部分“云“的工作，减轻云中心的压力，同时也可以满足一些业务本地处理的安全要求，还能减少复杂网络中各种路由转发和网络设备处理的时延，更加能大幅减少网络传输和多级转发带来的带宽成本。如此一来，既能解决处理能力问题，又能优化成本的问题。

应用场景

云边端协同业务主要有以下业务场景。

AI业务场景：如AI视频监控-监控视频产生大量的数据，同时AI视频分析需要大量的计算能力。如果在终端上进行视频AI分析，会大量消耗端的算力，终端无可避免的需要庞大的体积来承载这些算力；又如果将AI计算放在云中心，又将面临高昂的视频传输成本。这时候，终端算力上移、云端算力下沉，在边缘形成算力融合，在云上训练，边缘执行。即充分发挥云计算海量资源的优势，将 AI 模型的训练放在云端，而 AI 的执行则贴近设备侧，提高AI的执行效率与速度。

边缘分发：将业务内容下发到离用户近的边缘节点，让用户可以就近访问需要的内容，不必去中心云访问内容，减少了传输时延，提升用户的业务体验，同时，缓解传统架构中网络压力，减少了中心云的带宽成本。

VR云渲染：在云端对VR内容进行渲染，对VR内容延迟响应要求及带宽需求极高，当渲染延迟大于30ms时，会使用户感到眩晕，同时会造成VR内容视野内出现黑边。通过将渲染平台部署到边缘，实现渲染计算资源在边缘完成回传给用户，减少了网络传输时延，实现业务的稳定。

基于云原生的边缘计算框架

Kubernetes已经成为云原生的主流选择，Kubernetes能够在任何基础设施上提供一致的云上体验。目前，不仅大多数新兴的云原生负载是构建在Kubernetes上的，传统应用和负载也在以更快的速度向Kubernetes迁移。而且Kubernetes 在朝着大规模，复杂场景的方向延伸，与AI、大数据、IoT、以及垂直行业等领域的结合越来越紧密。近年来，越来越多围绕Kubernetes生态圈的创新，正在这些领域发生着。把 Kubernetes 从云端延伸到边缘，目前有三个开源项目讨论较多，分别是OpenYurt、 KubeEdge 和 K3S，下面将详细介绍这三个开源框架。

OpenYurt

概述

OpenYurt 是一款云原生边缘计算框架，由阿里云开源。主打“云边一体化”概念，依托 Kubernetes 强大的容器应用编 排能力，满足了云-边一体化的应用分发、交付、和管控的诉求。相较于其他基于 Kubernetes 的边缘计 算框架，OpenYurt 秉持着“最小修改”原则，通过在边缘节点安装 Yurthub 组件，在云端部署 Yurtcontroller-manager组件，保证了在对 Kubernetes 零侵入的情况下，提供管理边缘计算应用所需的相 关能力。OpenYurt 能帮用户解决在海量边、端资源上完成大规模应用交付、运维、管控的问题，并提 供中心服务下沉通道，实现和边缘计算应用的无缝对接。

OpenYurt架构分为云端和边缘端两部分，主要设计理念为集中的Kubernetes master节点驻留在云 端，它管理驻留在边缘端的多个边缘节点。每个边缘节点都有适度的计算资源，允许运行多个边缘应用 程序和节点守护进程，群集中的边缘节点可以跨越多个物理区域。

架构

主要组件如下：

YurtHub：是一个运行在边缘节点上的节点守护程序，用作Kubernetes节点守护程序 (Kubelet，Kubeproxy，CNI插件等)的出站流量的代理。它在边缘节点的本地存储中缓存 Kubernetes节点守护程序可能访问的所有资源的状态。如果边缘节点处于脱机状态，这些守护程 序可以通过访问缓存来获取资源状态信息，在节点重新启动恢复正常时再从APIServer同步状态。

Yurt控制器管理器：是一个部署在云端节点的组件，承接了原kube-controller-manager中的一些 工作。针对不同的边缘计算用例，它管理一些控制器，例如节点控制器(已发布)、单元控制器 (未发布)和隧道服务器(未发布)。其目前主要应用场景例如， autonomy 模式下的节点，即使 缺少节点心跳，也不会从APIServer退出处于该模式的节点中的Pod。

Yurt隧道(未发布)：为云端控制节点和已联网的边缘节点之间建立安全的网络访问。其主要实 现方式为部署在云端的 Tunnel Server 通过反向代理的方式与部署在每个边缘节点中守护程序 TunnelAgent 建立通信通道。通过YurtTunnel建立内部网络流量通道，保证数据安全，同时解决了租用私有网络，带宽有限，且延迟高的问题。

特点

OpenYurt秉持着“最小修改”原则，对K8S零侵入，基于标准K8S API及标准网络技术实现，使得其具有 强兼容性，易于集成，提供一键集群转化功能，最大程度保证用户在管理边缘应用时获得和管理云端应 用一致的体验。YurtTunnel建立内部网络流量通道，保证数据安全，同时解决了租用私有网络，带宽有 限，且延迟高的问题。通过云上管控，边缘自治(YurtController+YurtHub)架构，一方面把云上把 Kubernetes原生容器编排和调度延伸至边缘，另一方面，在网络不稳，或边缘离线的状态下，保证离 线自治，应用继续工作。虽然OpenYurt 刚刚开源，当前开放的能力还不多，但是从其规划上看，未来 一年内将会有较大的提升及完善。

KubeEdge

概述

KubeEdge是基于Kubernetes构建的云边协同开源框架，可将容器化应用扩展到边缘端设备。其对Kubernetes侵入性较低，提供网络和应用程序提供核心基础架构支持，可完美支持ARM架构和x86架构。KubeEdge分为三个层面：云、边、端。KubeEdge可以做到云边可靠性协同，主要依赖于核心模块Cloud Hub同Edge Hub之间的数据传输通道，协议支持WebSocket和QUIC两种，保障云边信息同步：Cloud Hub基于WebSocket服务端，用于大量的边缘节点基于websocket协议连接上来，并监听云端的变化，缓存并发送消息到EdgeHub。Edge Hub基于WebSocket客户端，负责将接收到的信息转发到各边缘节点的各功能模块处理，同时将来自各edge端的消息通过隧道发送到cloud侧。

架构

Controllers包括EdgeController和DeviceController两个模块。

EdgeController: 用于控制 Kubernetes API Server 与边缘的节点、应用和配置的状态同步。

DeviceController: DeviceController 是一个扩展的 Kubernetes 控制器，管理边缘设备，确保设备信息、设备状态的云边同步。

MetaManager：通过本地数据库存储边缘端同云端通信时的所有信息，当云端需要查询数据时，直接从本地获取。假如云边网络不稳定时，本地数据库也能保障业务正常进行，在网络通信正常后，再重新同步数据。

Edged：相当于k8s中轻量版的kubelet,裁减掉边缘端多余功能，只维护核心的组件，管理pod生命周期。使EdgeCore做到极致轻量。

EventBus：MQTT客户端，为其他组件提供订阅和发布功能。

ServiceBus：接受来自云上服务的请求，与运行在边缘端的HTTP服务器交互，提供了云上服务通过HTTP协议访问边缘端HTTP服务器的能力。

DeviceTwin：负责存储设备状态并将设备状态同步到云，它还为应用程序提供查询接口。

KubeEdge实现边缘节点应用管理，利用Cloud Hub和Edge Hub消息传输机制，可在云端管理边缘端的应用，进行升级、更新。

由于工业场景设备会使用不同的协议，如蓝牙、Zigbee、Modbus等，若使用KubeEdge交互，需要通过Mapper将协议转成MQTT，最终才能实现设备同云端的通信。

特点

KubeEdge基于Kubernetes构建，并将k8s的能力扩展至边缘侧，保留了 Kubernetes 的管理面，重新开发了节点agent，大幅度优化使边缘组件资源占用更低。其通过底层优化的多路复用消息通道优化了云边的通信的性能。底层完美支持 ARM 架构和 x86 架构，满足更多异构服务器的管理。边缘侧极致轻量，占用资源约70M。云端中心可对边缘节点应用管理，统一进行应用分发、升级等。KubeEdge丰富了应用和协议支持，目前已经支持和计划支持的有：MQTT、BlueTooth、OPC UA、Modbus等，通过Mapper模块进行设备协议转换，实现设备的海量接入、实时通信。

K3S

概述

K3S是由Rancher公司开源的一套基于Kubernetes的轻量化云原生框架。K3S专为在资源有限的环境中运行 Kubernetes 的研发和运维人员设计，目的是为了在 x86、ARM64 和 ARMv7D 架构的边缘节点上运行小型的 Kubernetes 集群。K3S 的所有组件(包括 Server 和 Agent)都运行在边缘，因此不涉及云边协同。K3S 应用到边缘计算还需要搭配Rancher公司自己的Rancher平台进行使用，通过Rancher平台实现边缘云的管理、监控。

架构

k3s相比于的Kubernetes发行版，有以下更改：

• 移除过时的功能、Alpha功能、非默认功能，这些功能在大多数Kubernetes集群中已不可用，除此之外，K3S 还删除了所有非默认的 Admission Controller，in-tree 的 cloud provider 和存储插件。

• 删除内置插件(比如云供应商插件和存储插件)，可用外部插件程序替换。

• 使用 containderd 替换 Docker，减少运行时占用空间。

• 引入 SQLite 代替 etcd 作为管理面数据存储，并用 SQLite 实现了 list/watch 接口，即 Tunnel Proxy。

• 整合打包进程。为了节省内存，K3S 将原本以多进程方式运行的 Kubernetes 管理面和数据面的多个进程分别合并成一个来运行。

• 包含在一个简单的启动程序当中，可以处理复杂的TLS和其他选项。

• 几乎没有操作系统依赖性(仅需要健全的内核和cgroup挂载)。k3s软件包所需的依赖：

• containerd
• Flannel
• CoreDNS
• CNI
• 主机系统服务 (iptables, socat, etc)

K3S Server：相当于Kubernetes的master节点，即Kubernetes管理面组件+ SQLite 和 Tunnel Proxy，使用SQLite作为数据库。

K3S Agent:相当于Kubernetes的work节点，即 Kubernetes 的数据面 + Tunnel Proxy，默认使用containerd作为容器。

Tunnel Proxy：负责维护K3S Server和K3S Agent 之间的链接，采用Basic Auth的方式进行认证。

Containerd：替换了docker，k3s自身的kubelet通过cri-containerd plugin来驱动containerd创建Pod。

K3S的边缘计算架构相比其它边缘计算云原生架构，通过将Rancher自己的管理平台管理整个云原生系统，在每个边缘节点则部署完整的自治的K3S集群，在Rancher的管理平台实现边缘节点的统一纳管，可以实现边缘节点的业务部署及开通，负责跨集群的应用管理、监控、告警、日志、安全和策略。

特点

轻量化的Kubernetes，二进制文件包小于 40 mb，只需要 512MB RAM 即可运行

边缘是一套完整的K3S系统。

通过Rancher对边缘节点进行管理，每个边缘节点都是完整一套K3S集群。

开源框架功能对比

建议与思考

依托云原生的边缘计算开源框架有利于发挥云原生轻量化、易移植等优势，帮助企业快速构建云边端能力，有利于应用在云网边端之间平滑移动，后续还需思考运营商网络能力如何在边缘计算架构下进行能力延伸，提供混合云架构的边缘计算网络能力，以及思考企业应用在云边端协同架构的应用能力分解和协同。