大规模 IoT 边缘容器集群管理的几种架构-4-Kubeedge

前文回顾

1.大规模 IoT 边缘容器集群管理的几种架构-0-边缘容器及架构简介[1]2.大规模 IoT 边缘容器集群管理的几种架构-1-Rancher+K3s[2]3.大规模 IoT 边缘容器集群管理的几种架构-2-HashiCorp 解决方案 Nomad[3]4.大规模 IoT 边缘容器集群管理的几种架构-3-Portainer[4]

📚️Reference: IoT 边缘计算系列文章[5]

Kubeedge

kubeedge-horizontal-color

简介

KubeEdge 是一个开源系统，用于将本地容器化应用协调能力扩展到边缘的主机。它建立在 kubernetes 之上，为网络、应用部署和云与边缘之间的元数据同步提供基本的基础设施支持。

Kubeedge 的目标是建立一个开放的平台来实现边缘计算，将原生的容器化应用协调能力扩展到边缘的主机，该平台建立在 kubernetes 之上，为云和边缘之间的网络、应用部署和元数据同步提供基本的基础设施支持。

参考架构

•“云”：Kubernetes 集群 + CloudCore（包括： CloudHub、EdgeController、DeviceController）•“边”：EdgeCore•Edged: 轻量化的 Kubelet 实现•EdgeHub•DeviceTwin•MetaManager•ServiceBus•"端": 各类 IoT 设备 Mappers

kubeedge 架构

CloudCore 架构

EdgeCore Arch

方案优点

•CNCF 首个云原生边缘计算项目: 基于 Kubernetes, 为边缘做了很多优化和适配。功能强大且完善。全球开发者众多。•大规模: 单集群突破 10 万边缘节点•边缘设备管理: 完善的边缘设备管理，支持多种边缘设备通信协议，如 MQTT、Modbus、Bluetooth、OPC UA 等，支持自定义插件扩展边缘设备协议。•100%兼容 Kubernetes 原生能力： 支持用户使用 Kubernetes 原生 API 统一管理边缘应用•边缘可靠的 list-watch 接口•轻量： 针对资源受限场景进行自身组件轻量化，~70MB 内存占用•支持复杂的边云网络环境： 双向多路复用的边云消息通道，支持边缘位于私有网络； 应用层可靠增量同步机制，支持在高时延、低质量网络环境下工作•边缘自治: 支持边缘离线自治：边缘元数据持久化、边缘 DNS，保证边缘离线时的业务运行和故障恢复能力（相比起来，k3s 的边缘自治算是"伪边缘自治"); 支持边缘数据流式处理，定义边缘数据清洗、数据分析等处理工作•边云一体资源调度和流量协同: 支持边缘节点 (edged 节点，在 kubernetes 看来也是一个 node) 和云节点混合管理，提供边云数据通信和边边数据通信•DMI 架构设备管理: 管理面数据与业务面数据分离•EdgeMesh: 跨云边、边边的应用互访通信；边缘内置域名解析能力，不依赖中心 DNS; 支持 L4，L7 流量治理；支持跨越边云的一致的服务发现和访问体验；跨子网通信•Sedna: AI 边云协同套件

方案缺点

•复杂度高: Kubeedge 基于 Kubernetes, 但是针对边缘计算场景做了大量的功能扩展，这使得要用好 Kubeedge, 不仅要懂 Kubernetes, 还需要懂 Kubeedge, 还需要懂边缘业务/边缘通信协议。入门学习曲线极为陡峭。•中文文档质量一般: 查看 Kubeedge 官网中文文档，发现以下问题：版本更新后文档未更新；文档生硬机翻英文文档；文档组织结构存在问题，很难"quick start"; 甚至还有低级的文档排版错乱，markdown 错乱等问题。•反面典型案例：使用 Keadm 进行部署 | KubeEdge 一个支持边缘计算的开放平台[6], 看得我脑壳痛😂😂😂•资源占用其实也不少: 如果只是安装 edgecore 或 edged, 资源占用相对可控。如果需要使用到更多的功能，如 EdgeMesh, Sedna, 边缘设备管理，Kubernetes 的 CSI CNI 实现，那么这些功能都需要启用或额外安装相应插件。导致资源占用上升。•边缘容器管理和边缘计算业务有一定耦合: Kubeedge 除了提供边缘容器管理基本功能外，还提供了大量与边缘计算业务有密切关系的功能，可能会导致部门耦合。•自动化运维困难: 其他 3 个方案，都会提供一键式的安装运维脚本或自动化部署/运维功能，Kubeedge 这方面相对缺乏，自动化运维能力需要自行探索。

参考资料

•使用 Keadm 进行部署 | KubeEdge 一个支持边缘计算的开放平台[8]