KubeEdge 是华为捐献给 CNCF 的第一个开源项目，也是全球首个基于 Kubernetes 扩展的，提供云边协同能力的开放式边缘计算平台。KubeEdge 的名字来源于 Kube + Edge，顾名思义就是依托 Kubernetes 的容器编排和调度能力，实现云边协同、计算下沉、海量设备接入等。
K3S 是 Rancher 开源的一个自己裁剪的 Kubernetes 发行版，K3S 名字来源于 K8s – 5，这里的“5”指的是 K3S 比 Kubernetes 更轻量使得它能更好地适配 CI，ARM，边缘技术，物联网和测试这 5 个场景。
同样是基于 Kubernetes，同样是致力于解决边缘场景问题的开源软件，这两个项目不免经常被人拿来比较。本文将以边缘计算的实际场景和挑战为出发点，为您剖析 Kubernetes 能够在边缘计算领域的发力点，最后全方位对比 KubeEdge 和 K3S。
边缘计算场景分类与挑战
这里要讨论的“边缘”特指计算资源在地理分布上更加靠近设备，而远离云数据中心的资源节点。典型的边缘计算分为物联网（例如：下一代工业自动化，智慧城市，智能家居，大型商超等）和非物联网（例如：游戏，CDN 等）场景。
在现实世界中，边缘计算无法单独存在，它必定要和远程数据中心 / 云打通（具体原因见下文）。以 IoT（Internet of Things，物联网）为例，边缘设备除了拥有传感器收集周边环境的数据外，还会从云端接收控制指令。边缘设备与云连接一般有两种模式：直连和通过中继边缘节点连接，如下图所示:
边缘设备能否直连云端 / 数据中心取决于是否有全球唯一可路由的 IP，例如：手机、平板电脑等。不过，大部分的设备通过近场通信协议与边缘节点通信，进而和云端 / 数据中心连接的。边缘节点是设备的汇聚点，有分配 IP 地址，扮演了边缘网关的作用。边缘节点为普通的设备提供 IP 地址，也可以运行容器。
我们注意到，边缘节点也是有不同层级的，而划分的标准之一就是资源（计算、存储、网络带宽等）的大小。
如上所示，我们将 edge 分为“Device Edge”和“Infrastructure Edge”。Device Edge（设备边缘）是指那些并不被认为是 IT 基础设施组成部分的边缘节点，例如：火车、油田、工厂和家庭等。通常它们没什么计算能力，被用于解决最后“一公里”接入的问题，一个典型的例子就是智能路由器，它一端通过红外信号控制家中电器，另一端通过网络和云数据中心相连。由于设备边缘网络稳定性较差，因此必须要考虑它们会较长时间离线的情况（例如火车过隧道）。
注：日常生活中很多设备我们可以看成是 device+device edge 的结合体，例如智能手机。
nfrastructure Edge（基础设施边缘）相对于 Device Edge 计算和存储能力都更强，而且通常通过骨干网与数据中心连接，因此具有更大的网络带宽和更加可靠的网络连接，例如：CDN，游戏服务器等。基础设施边缘除了能运行容器外，有些甚至还有足够资源运行完整的 Kubernetes。
对边缘节点进行分类的意义在于，针对不同层级的边缘需要有针对性的部署模型，并且平台要为边缘节点提供通信能力。
最后，我们总结一下当前边缘计算领域面临的几个挑战：
云边协同：AI/ 安全等业务在云和边的智能协同、弹性迁移；
网络：边缘网络的可靠性和带宽限制；
管理：边缘节点的资源管理与边缘应用生命周期管理；
扩展：高度分布和大规模的可扩展性；
异构：边缘异构硬件和通信协议。
其中，云边协是当前面临最大的技术挑战！
为什么我们需要云边协同
边缘计算和云计算不是两种互斥的技术，它们是相辅相成的关系。而且从场景需求上看，IoT/Edge 与云数据中心有一些相似之处，例如：
边缘也有管理节点的计算、存储、网络等资源的需求；
边缘应用也想容器化和微服务化；
边缘计算希望能有标准的 API 和工具链；
安全，数据 / 信道加密和认证授权。
因此，将云数据中心的现有架构和能力顺势延伸到边缘就变得水到渠成了。下面列举了一些需要云边协同的场景：
AI 云上训练，边缘执行。即充分发挥云计算海量资源的优势，将 AI 模型的训练放在云端，而 AI 的执行则贴近设备侧；
微服务，DevOps。微服务和 DevOps 不仅仅是云上开发的专利，将它们引入边缘将会显著加速嵌入式设备、机器人等 IoT 软件的迭代周期，提升部署和运维效率；
数据备份转储。例如，海量的工业数据（加密后）存储在云端；
远距离控制。云端远程下发对边缘设备的控制信号；
自动扩展。由于边缘节点不如云具备良好的自动扩展能力，因此可以选择在峰值时将边缘的负载弹性扩容到云上。
我们已经积累了足够的管理云上资源的经验，现在下一步的挑战就是如何构建一个边缘云平台，把对云上资源的管理方法延伸到边缘，让我们能够无缝地管理边缘的资源和设备。边缘云平台将重点解决以下问题：
大规模 / 异构的设备，网关和边缘节点的接入；
大量遥测数据汇聚、处理后提供给云端应用使用；
设备安全和识别服务；
支持远程下达对设备的指令；
自动创建和管理边缘节点和设备；
实现云端对边缘应用的编排、部署和配置；
为边缘应用的开发提供数据存储、事件管理、API 管理和数据分析等能力。
Kubernetes 的优势与挑战
ubernetes 已经成为云原生的标准，并且能够在任何基础设施上提供一致的云上体验。我们经常能够看到“容器 + Kubernetes”的组合在 DevOps 发挥 10X 效率，最近也有越来越多 Kubernetes 运行在数据中心外（边缘）的需求。
如果要在边缘部署较复杂的应用，那么 Kubernetes 是个理想的选择：
容器的轻量化和可移植性非常适合边缘计算的场景；
Kubernetes 已经被证明具备良好的可扩展性；
能够跨底层基础设施提供一致的体验；
同时支持集群和单机运维模式；
Workload 抽象，例如：Deployment 和 Job 等；
应用的滚动升级和回滚；
围绕 Kubernetes 已经形成了一个强大的云原生技术生态圈，诸如：监控、日志、CI、存储、网络都能找到现成的工具链；
支持异构的硬件配置（存储、CPU、GPU 等）；
用户可以使用熟悉的 kubectl 或者 helm chart 把 IoT 应用从云端推到边缘；
边缘节点可以直接映射成 Kubernetes 的 Node 资源，而 Kubernetes 的扩展
API（CRD）可以实现对边缘设备的抽象。
然而 Kubernetes 毕竟是为云数据中心设计的，要想在边缘使用 Kubernetes 的能力，Kubernetes 或其扩展需要解决以下问题：
ARM 的低功耗和多核的特点又使得其在 IoT/Edge 领域的应用非常广泛，然而大部分的 Kubernetes 发行版并不支持 ARM 架构；
很多设备边缘的资源规格有限，特别是 CPU 处理能力较弱，因此无法部署完整的 Kubernetes；
Kubernetes 非常依赖 list/watch 机制，不支持离线运行，而边缘节点的离线又是常态，例如：设备休眠重启；
Kubernetes 的运维相对于边缘场景用到的功能子集还是太复杂了；
特殊的网络协议和拓扑要求。设备接入协议往往非 TCP/IP 协议，例如，工业物联网的 Modbus 和 OPC UA，消费物联网的 Bluetooth 和 ZigBee 等；
设备多租。
关于如何在边缘使用 Kubernetes，Kubernetes IoT/Edge WG 组织的一个调查显示，30% 的用户希望在边缘部署完整的 Kubernetes 集群，而 70% 的用户希望在云端部署 Kubernetes 的管理面并且在边缘节点上只部署 Kubernetes 的 agent。
把 Kubernetes 从云端延伸到边缘，有两个开源项目做得不错，分别是 KubeEdge 和 K3S，下面我们将详解这两个项目，并做全方位的对比。
KubeEdge 架构分析
KubeEdge 是首个基于 Kubernetes 扩展的，提供云边协同能力的开放式智能边缘平台，也是 CNCF 在智能边缘领域的首个正式项目。KubeEdge 重点要解决的问题是：
云边协同
资源异构
大规模
轻量化
一致的设备管理和接入体验
KubeEdge 的架构如下所示：
KubeEdge 架构上清晰地分为三层，分别是：云端、边缘和设备层，这是一个从云到边缘再到设备的完整开源边缘云平台，消除了用户厂商绑定的顾虑。
KubeEdge 的边缘进程包含以下 5 个组件：
edged 是个重新开发的轻量化 Kubelet，实现 Pod，Volume，Node 等 Kubernetes 资源对象的生命周期管理；
metamanager 负责本地元数据的持久化，是边缘节点自治能力的关键；
edgehub 是多路复用的消息通道，提供可靠和高效的云边信息同步；
devicetwin 用于抽象物理设备并在云端生成一个设备状态的映射；
eventbus 订阅来自于 MQTT Broker 的设备数据。
KubeEdge 的云端进程包含以下 2 个组件：
cloudhub 部署在云端，接收 edgehub 同步到云端的信息；
edgecontroller 部署在云端，用于控制 Kubernetes API Server 与边缘的节点、应用和配置的状态同步。
Kubernetes maser 运行在云端，用户可以直接通过 kubectl 命令行在云端管理边缘节点、设备和应用，使用习惯与 Kubernetes 原生的完全一致，无需重新适应。
K3S 架构分析
K3S 是 CNCF 官方认证的 Kubernetes 发行版，开源时间较 KubeEdge 稍晚。K3S 专为在资源有限的环境中运行 Kubernetes 的研发和运维人员设计，目的是为了在 x86、ARM64 和 ARMv7D 架构的边缘节点上运行小型的 Kubernetes 集群。K3S 的整体架构如下所示：
事实上，K3S 就是基于一个特定版本 Kubernetes（例如：1.13）直接做了代码修改。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 接口，即 Tunnel Proxy；
加了一个简单的安装程序。
K3S 的所有组件（包括 Server 和 Agent）都运行在边缘，因此不涉及云边协同。如果 K3S 要落到生产，在 K3S 之上应该还有一个集群管理方案负责跨集群的应用管理、监控、告警、日志、安全和策略等，遗憾的是 Rancher 尚未开源这部分能力。
KubeEdge 与 K3S 全方位对比
部署模型
KubeEdge 遵循的是以下部署模型:
KubeEdge 是一种完全去中心化的部署模式，管理面部署在云端，边缘节点无需太多资源就能运行 Kubernetes 的 agent，云边通过消息协同。从 Kubernetes 的角度看，边缘节点 + 云端才是一个完整的 Kubernetes 集群。这种部署模型能够同时满足“设备边缘”和“基础设施边缘”场景的部署要求。
K3S 的部署模型如下所示：
K3S 会在边缘运行完整的 Kubernetes 集群，这意味着 K3S 并不是一个去中心化的部署模型，每个边缘都需要额外部署 Kubernetes 管理面。这种部署模型带来的问题有：
在边缘安装 Kubernetes 管理面将消耗较多资源，因此该部署模型只适合资源充足的“基础设施边缘”场景，并不适用于资源较少的“设备边缘”的场景；
集群之间网络需要打通；
为了管理边缘 Kubernetes 集群还需要在上面叠加一层多集群管理组件（遗憾的是该组件未开源）。
云边协同
云边协同是 KubeEdge 的一大亮点。KubeEdge 通过 Kubernetes 标准 API 在云端管理边缘节点、设备和工作负载的增删改查。边缘节点的系统升级和应用程序更新都可以直接从云端下发，提升边缘的运维效率。另外，KubeEdge 底层优化的多路复用消息通道相对于 Kubernetes 基于 HTTP 长连接的 list/watch 机制扩展性更好，允许海量边缘节点和设备的接入。KubeEdge 云端组件完全开源，用户可以在任何公有云 / 私有云上部署 KubeEdge 而不用担心厂商锁定，并且自由集成公有云的其他服务。
K3S 并不提供云边协同的能力。
边缘节点离线自治
与 Kubernetes 集群的节点不同，边缘节点需要在完全断开连接的模式下自主工作，并不会定期进行状态同步，只有在重连时才会与控制面通信。此模式与 Kubernetes 管理面和工作节点通过心跳和 list/watch 保持状态更新的原始设计非常不同。
KubeEdge 通过消息总线和元数据本地存储实现了节点的离线自治。用户期望的控制面配置和设备实时状态更新都通过消息同步到本地存储，这样节点在离线情况下即使重启也不会丢失管理元数据，并保持对本节点设备和应用的管理能力。
K3S 也不涉及这方面能力。
设备管理
KubeEdge 提供了可插拔式的设备统一管理框架，允许用户在此框架上根据不同的协议或实际需求开发设备接入驱动。当前已经支持和计划支持的协议有：MQTT，BlueTooth，OPC UA，Modbus 等，随着越来越多社区合作伙伴的加入，KubeEdge 未来会支持更多的设备通信协议。KubeEdge 通过 device twins/digital twins 实现设备状态的更新和同步，并在云端提供 Kubernetes 的扩展 API 抽象设备对象，用户可以在云端使用 kubectl 操作 Kubernetes 资源对象的方式管理边缘设备。
K3S 并不涉及这方面能力。
轻量化
为了将 Kubernetes 部署在边缘，KubeEdge 和 K3S 都进行了轻量化的改造。区别在于 K3S 的方向是基于社区版 Kubernetes 不断做减法（包括管理面和控制面），而 KubeEdge 则是保留了 Kubernetes 管理面，重新开发了节点 agent。
需要注意的是，K3S 在裁剪 Kubernetes 的过程中导致部分管理面能力的缺失，例如：一些 Admission Controller。而 KubeEdge 则完整地保留了 Kubernetes 管理面，没有修改过一行代码。
下面我们将从二进制大小、内存和 CPU 三个维度对比 KubeEdge 和 K3S 的资源消耗情况。由于 KubeEdge 的管理面部署在云端，用户不太关心云端资源的消耗，而 K3S 的 server 和 agent 均运行在边缘，因此下面将对比 KubeEdge agent，K3S agent 和 K3S server 这三个不同的进程的 CPU 和内存的资源消耗。
测试机规格为 4 vCPU，8GB RAM。
内存消耗对比
分别用 KubeEdge 和 K3S 部署 0~100 个应用，分别观测两者的内存消耗，对比如下所示：
从上图可以看出，内存消耗：KubeEdge agent < K3S agent < K3S Server。有意思的是，K3S agent 即使不运行应用也消耗 100+MB 的内存，而 K3S server 在空跑的情况下内存消耗也在 300MB 左右。
CPU 使用对比
分别用 KubeEdge 和 K3S 部署 0~100 个应用，分别观测两者的 CPU 使用情况，对比如下所示：
从上图可以看出，KubeEdge agent CPU 消耗要比 K3S agent 和 server 都要少。
二进制大小
KubeEdge agent 二进制大小为 62MB，K3S 二进制大小为 36MB。
大规模
Kubernetes 原生的可扩展性受制于 list/watch 的长连接消耗，生产环境能够稳定支持的节点规模是 1000 左右。KubeEdge 作为华为云智能边缘服务 IEF 的内核，通过多路复用的消息通道优化了云边的通信的性能，压测发现可以轻松支持 5000+ 节点。
而 K3S 的集群管理技术尚未开源，因为无法得知 K3S 管理大规模集群的能力。
小结
K3S 最让人印象深刻的创新在于其对 Kubernetes 小型化做的尝试，通过剪裁了 Kubernetes 一些不常用功能并且合并多个组件到一个进程运行的方式，使得一些资源较充足的边缘节点上能够运行 Kubernetes，让边缘场景下的用户也能获得一致的 Kubernetes 体验。然而通过上面的性能对比数据发现，K3S 的资源消耗还是比 KubeEdge 要高出好几倍，而且动辄几百 MB 的内存也不是大多数设备边缘节点所能提供的。最重要的是，Kubernetes 最初是为云数据中心而设计的，很多边缘计算场景特殊的问题原生 Kubernetes 无法很好地解决， K3S 直接修改 Kubernetes 的代码甚至基础实现机制（例如，使用 SQLite 替换 etcd）的做法仍值得商榷。关于什么能改，什么不能改以及怎么改？每个用户根据自己的实际需求有各自的观点，而且也很难达成一致。另外， K3S 这种侵入式的修改能否持续跟进 Kubernetes 上游的发展也是一个未知数。
KubeEdge 和 K3S 走的是另一条道路，KubeEdge 是一个从云到边缘再到设备的完整边缘云平台，它与 Kubernetes 的耦合仅仅是 100% 兼容 Kubernetes 原生 API。KubeEdge 提供了 K3S 所不具备的云边协同能力，开发了更轻量的边缘容器管理 agent，解决了原生 Kubernetes 在边缘场景下的离线自治问题，并且支持海量异构边缘设备的接入等。KubeEdge 最近捐献给 CNCF，成为 CNCF 边缘计算领域的第一个正式项目，就是为了和社区合作伙伴一起制定云和边缘计算协同的标准，结束边缘计算没有统一标准和参考架构的混沌状态，共同推动边缘计算的产业发展。
最后，边缘计算还有广阔的发展前景，KubeEdge 和 K3S 都是非常年轻的优秀开源项目，我相信未来他们会在相互学习的过程中 共同进步，更好地解决边缘计算用户的需求。
来源(版权归者所有)：https://bbs.huaweicloud.com/blogs/116815
