共计 5040 个字符，预计需要花费 13 分钟才能阅读完成。
摘要：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 正式我的项目，将来将继续与社区合作伙伴一起制订云和边缘计算协同的规范，解决边缘计算畛域的难题，完结边缘计算没有统一标准和参考架构的混沌状态，独特推动边缘计算的产业倒退。
点击关注，第一工夫理解华为云陈腐技术~
