前文回顾
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]