摘要：KubeEdge 是首个基于 Kubernetes 扩展的，提供云边协同能力的开放式智能边缘计算平台，也是 CNCF 在智能边缘领域的首个正式项目。依托 Kubernetes 强大的容器编排和调度能力，实现云边协同、计算下沉、海量设备接入等。

边缘计算场景与挑战

边缘计算是一种分布式计算概念，拥有去中心化处理能力的分散型开放 IT 架构，数据由设备本身或本地计算机或服务器处理，无需传输到数据中心，也可在更靠近终端的网络边缘上提供服务。

但边缘计算无法单独存在，它必定要和远程数据中心 / 云打通，以 IoT（Internet of Things，物联网）场景为例，边缘设备除了拥有传感器收集周边环境的数据外，还会从云端接收控制指令，因此边缘计算与云计算二者是相依而生、协同运作的。

据2020边缘计算状态报告显示，到2022年，75%的数据将通过边缘分析和处理。这种数据处理的流动性，将伴随有4大边缘技术演进方向：

• 人工智能的实用性增强，从云端渗透到边缘
• 物联网设备的数量呈指数级增长
• 5G时代的快速到来
• 边缘计算中心逐步克服分布式设施复杂性和单位成本经济性的问题

结合边缘计算的场景与技术演进方向，可以总结出当前边缘计算领域面临的几个挑战：

• 云边协同：逐步从云端渗透到边缘的AI/安全等业务，在云和边的智能协同、弹性迁移；
• 网络：边缘网络的可靠性和带宽限制；
• 设备管理：呈指数级增长的物联网设备，边缘节点与边缘设备的管理；
• 扩展：高度分布和大规模的可扩展性；
• 异构：边缘异构硬件和通信协议。

Kubernetes构建边缘计算平台的优势与挑战

Kubernetes 已经成为云原生的事实标准，并且能够在任何基础设施上提供一致的云上体验。我们经常能够看到“容器 + Kubernetes”的组合在 DevOps 发挥 10X 效率。基于Kubernetes的技术架构与生态优势，近几年也有越来越多的将Kubernetes 运行在数据中心外（边缘）的需求。

基于Kubernetes构建的边缘计算平台，将会具备众多天然的优势：

（1）容器化应用封装：容器的轻量化和可移植性非常适合边缘计算的场景，边缘容器应用Build一次，可以运行在任何边缘节点上。

（2）通用的应用抽象定义：Kubernetes的应用定义已成为云原生业界的事实标准，被广泛接受。通过原生的Kubernetes应用API，用户可以将云上与边缘的应用统一管理。例如用户可以使用熟悉的 kubectl 或者 helm chart管理云上与边缘的应用。

（3）平台易扩展性：Kubernetes 已经被证明具备良好的可扩展性，基于CRD可以自定义API，如边缘设备管理；基于CRI、CNI、CSI等插件可以扩展各种边缘自定义插件。

（4）强大的技术生态圈：围绕 Kubernetes 已经形成了一个强大的云原生技术生态圈，诸如：监控、日志、CI、存储、网络都能找到现成的工具链。

然而 Kubernetes 毕竟原生是为云数据中心设计的，要将Kubernetes 的能力扩展到边缘，必须解决以下问题：

（1）边缘设备资源有限：很多设备边缘的资源规格有限，特别是 CPU 处理能力较弱，内存资源较少，因此无法部署完整的 Kubernetes。

（2）边缘网络的不稳定性：Kubernetes依赖数据中心稳定的网络，边缘场景下网络通常又是不稳定的。

（3）边缘节点离线自治：Kubernetes依赖 list/watch 机制，不支持离线运行，而边缘节点的离线又是常态，例如：设备离线重启。

（4）海量边缘设备管理：如何使用Kubernetes管理指数级增长的海量边缘设备以及产生的数据。

另外，关于如何在边缘使用 Kubernetes，Kubernetes IoT/Edge WG 组织的一个调查显示，30% 的用户希望在边缘部署完整的 Kubernetes 集群，而 70% 的用户希望在云端部署 Kubernetes 的管理面并且在边缘节点上只部署 Kubernetes 的 agent。

边缘容器开源现状

Kubernetes社区很早就已经关注到边缘计算场景，早在2018年社区就已经成立专门的Edge工作组来研讨边缘相关场景。而2018年底，华为在业界首次开源Kubernetes边缘项目KubeEdge，将华为云智能边缘平台产品IEF（Intelligent EdgeFabric）核心代码开源，并于19年初捐献给CNCF基金会，成为CNCF迄今为止唯一边缘计算官方项目。随后，Rancher、阿里云也陆续跟进，开源了K3s、OpenYurt等项目，边缘容器这个领域真正进入到快速发展期。下面，我们对这三个代表性的K8s@Edge的项目进行一些简要分析。

KubeEdge架构分析

KubeEdge 是华为云于2018年11月开源，2019年3月捐献给 CNCF 的开源项目。KubeEdge 是首个基于 Kubernetes 扩展的，提供云边协同能力的开放式智能边缘计算平台，也是 CNCF 在智能边缘领域的首个正式项目。KubeEdge 的名字来源于 Kube + Edge，顾名思义就是依托 Kubernetes 强大的容器编排和调度能力，实现云边协同、计算下沉、海量设备接入等。

KubeEdge架构上分为云、边、端三个层次。云端中心管控边缘节点与设备，边缘节点实现边缘自治，云上管控边缘节点的架构也符合Kubernetes IoT/Edge WG 调查结果中大多数用户的诉求。KubeEdge完整的打通了边缘计算中云、边、设备协同的场景，整体架构如下图。

针对边缘特定的场景，KubeEdge 重点解决的问题是：

云边协同：KubeEdge 通过 Kubernetes 标准 API 在云端管理边缘节点、设备和工作负载的增删改查。边缘节点的系统升级和应用程序更新都可以直接从云端下发，提升边缘的运维效率；在边缘AI场景下，云端训练好的模型可以直接下发到边缘节点，进行推理等，实现边缘AI的云边一体化。

边缘自治：KubeEdge 通过消息总线和元数据本地存储实现了节点的离线自治。用户期望的控制面配置和设备实时状态更新都通过消息同步到本地存储，这样节点在离线情况下即使重启也不会丢失管理元数据，并保持对本节点设备和应用的管理能力。

极致轻量：KubeEdge 则是保留了 Kubernetes 管理面，对Kubernetes的节点端组件进行重组，达到极致轻量的目的，节点组件可以运行在内存256M的边缘节点上。

海量边缘设备管理：KubeEdge了可插拔式的设备统一管理框架，在云端基于Kubernetes的CRD能力，自定义了设备管理的API，完全符合Kubernetes的原生标准，用户可以在云端通过API来管理海量边缘设备；在边缘可根据不同的协议或实际需求开发设备接入驱动，当前已经支持和计划支持的协议有：MQTT，BlueTooth，OPC UA，Modbus 等，随着越来越多社区合作伙伴的加入，KubeEdge 未来会支持更多的设备通信协议。

K3s架构分析

K3s 是 Rancher于2019年2月开源的一个自己裁剪的 Kubernetes 发行版，K3S 名字来源于 K8s – 5，这里的“5”指的是 K3S 比 Kubernetes 更轻量使得它能更好地适配 CI，ARM，边缘技术，物联网和测试这 5 个场景。K3S 是 CNCF 官方认证的 Kubernetes 发行版，开源时间较 KubeEdge 稍晚。K3S 专为在资源有限的环境中运行 Kubernetes 的研发和运维人员设计，目的是为了在 x86、ARM64 和 ARMv7D 架构的边缘节点上运行小型的 Kubernetes 集群。K3S 的整体架构如下所示：

K3S 就是基于一个特定版本 Kubernetes（例如：1.17）直接做了代码修改。K3S 分 Server 和 Agent，Server 就是 Kubernetes 管理面组件 + SQLite 和 Tunnel Proxy，Agent 即 Kubernetes 的数据面 + Tunnel Proxy。

为了减少运行 Kubernetes 所需的资源，K3S 对原生 Kubernetes 代码做了以下几个方面的修改：

删除旧的、非必须的代码。K3S 不包括任何非默认的、Alpha 或者过时的 Kubernetes 功能。除此之外，K3S 还删除了所有非默认的 Admission Controller，in-tree 的 cloud provider 和存储插件；

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

使用 Containderd 替换 Docker，显著减少运行时占用空间；

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

将所有Kubernetes原生进程打包在同一个进程中。

K3s项目本质上是一个K8s的“轻量化”版本，而不是一个真正意义上的“边缘”版本。从架构上看，K3s 的所有组件（包括 Server 和 Agent）都运行在边缘侧，这意味着 K3S 并不是一个去中心化的部署模型，每个边缘都需要额外部署 Kubernetes 管理面，因此不涉及云边协同。也缺乏针对边缘网络不稳定性的边缘自治能力，也不涉及边缘设备的管理。

此外，如果 K3s 要落到生产，在 K3s 之上应该还有一个云上的统一集群管理方案负责跨集群的应用管理、监控、告警、日志、安全和策略等，遗憾的是 Rancher 尚未开源这部分能力。

OpenYurt架构分析

OpenYurt是阿里云于2020年5月开源的云原生边缘计算项目，跟KubeEdge架构基本相似，OpenYurt也是依托原生Kubernetes的容器编排及调度能力，提供云边协同能力的边缘计算平台。OpenYurt 也是依托 Kubernetes 强大的容器应用编排能力，实现云-边一体化的应用分发、管控的诉求，也是从云端集中管控边缘节点，OpenYurt 的整体架构如下所示：

项目目前还未发布0.1版本，从已开源部分可以看出，OpenYurt架构与KubeEdge类似，也是打通了云边协同的场景。提供的能力也与KubeEdge类似，包括边缘自治、云边协同、单元化管理能力（未开源）等。

OpenYurt并未对Kubernetes进行改造，而是通过Addon（插件化）的形式提供边缘计算所需要的管控能力，边缘端的YurtHub，作为节点上的临时配置中心，在网络连接中断的情况下，持续为节点上所有设备和客户业务提供数据配置服务。这种简化的架构，重点在于解决“离线自治”问题，且比较有利于保留现有K8s的完整功能，但由于未对Kubelet进行修改，因此OpenYurt无法运行在资源有限的边缘设备中；物联网场景中的对于边缘设备的管理，OpenYurt也不涉及；并且一些边缘场景下涉及到Kubelet原生不支持的高级特性比如离线自愈、自调度等无法实现。

边缘容器总结与展望

对比三个开源项目， K3s 最让人印象深刻的特点在于其对 Kubernetes 进行了轻量化、部署便捷化做的尝试，通过剪裁了 Kubernetes 一些不常用功能并且合并多个组件到一个进程运行的方式，使得一些资源较充足的边缘节点上能够很方便的获得与Kubernetes一致的体验。但是从测试数据看K3s 的资源消耗还是很高，而且动辄几百 MB 的内存也不是大多数设备边缘节点所能提供的，而且目前只适合运行在边缘，不具备云边协同、边缘自治等边缘计算领域的核心诉求。

OpenYurt通过非侵入的插件化形式在原生Kubernetes的基础上提供边缘计算能力，虽然提供了云边协同、边缘自治等能力，但是未做轻量化改造，只能运行在资源充足的边缘节点，无法运行在大量资源有限的边缘节点上，并且也未提供边缘计算中海量边缘设备管理的能力。

KubeEdge是一个从云到边缘再到设备的完整边缘云平台，100% 兼容Kubernetes的原生API，基于Kubernetes解决了边缘计算领域的核心诉求，包括云边协同、边缘网络不稳定、边缘自治、边缘轻量化、海量边缘设备管理以及异构扩展等问题。

未来边缘容器技术仍将聚焦于解决边缘计算领域所面临的云边协同、网络、设备管理、扩展及异构等挑战，KubeEdge 已经是 CNCF正式项目，未来将持续与社区合作伙伴一起制定云和边缘计算协同的标准，解决边缘计算领域的难题，结束边缘计算没有统一标准和参考架构的混沌状态，共同推动边缘计算的产业发展。

点击关注，第一时间了解华为云新鲜技术~