边缘计算云原生开源方案选型比较

作者 | LanLiang

来源 | https://zhuanlan.zhihu.com/p/353429279?utm_source=wechat_session&utm_medium=social&utm_oi=958162902792843264&utm_content=group2_article&utm_campaign=shareopn&s_r=0

随着Kubernetes已经成为容器编排和调度的事实标准,各大公有云厂商都已经基于Kubernetes提供了完善的Kubernetes云上托管服务。同时也看到越来越多的企业、行业开始在生产中使用Kubernetes, 拥抱云原生。在各行各业数字化转型和上云过程中,公有云厂商也在主动拥抱传统线下环境,在思考各种各样的解决方案使云上能力向边缘(或线下)延伸。而Kubernetes由于屏蔽了底层架构的差异性,可以帮助应用平滑地运行在不同的基础设施上的特性,云上的Kubernetes服务也在考虑拓展其服务边界,云原生和边缘计算结合的想法自然就呼之欲出了。

目前国内各个公有云厂商也都开源了各自基于Kubernetes的边缘计算云原生项目。如华为云的KubeEdge,阿里云的OpenYurt,腾讯云的SuperEdge。目前网上很少有从技术视角来介绍这几个项目优缺点的文章,本文试着从技术视角,从开源视角来分析这几个项目,希望可以给大家做项目选型时提供一些借鉴。

1. 比较思路

这几个项目都是云边一体,云边协同的架构,走的是Kubernetes和边缘计算结合的路数,因此决定从以下几点比较:

(1) 各个项目的开源状况:比如开源项目的背景、开源的时间、是否进入了CNCF等;

(2)Kubernetes架构:

  • 先对比与Kubernetees的架构差异:主要关注是否修改Kubernetes,和;Kubernetes一键式转换等

  • 根据架构差异对比和Kubernetes的能力增强点;主要关注边缘自治,边缘单元化,轻量化等能力

  • 最后看一下架构差异可能带来的影响: 主要关注运维监控能力,云原生生态兼容性,系统稳定性等方面

(3)对边缘计算场景支持能力:

  • 主要关注是否具备端设备的管理能力

接下来以项目的开源顺序,从上述几个方面来介绍各个项目。

2.边缘云原生开源项目对比

2.1 KubeEdge

(1)开源状况

KubeEdge是华为云于2018年11月份开源的,目前是CNCF孵化项目。其架构如下:

水货CTO,将熊熊一窝

(2)与Kubernetes的架构差异

首先从架构图可以看到,云端(k8s master)增加了Cloud Hub组件和各类controller,而在边缘端(k8s worker)没有看到原生的kubelet和kube-proxy,而是一个对原生组件进行重写了EdgeCore组件。

从架构图看EdgeCore是基于kubelet重构的,为了保证轻量化,裁剪了原生kubelet的部分能力,同时也增加了很多适配边缘场景的能力。具体如下:

  • Cloud Hub+EdgeHub模块: 抛弃了原生kubernetes 的组件间数据同步list/watch机制,改成基于websocket/quic协议从云端往边缘推送模式。

  • 节点元数据缓存模块(MetaManager): 把节点维度的数据持久化在本机的SQLite数据库中,当云边网络不稳定时Edged模块将从本地数据库中获取数据用于业务的生命周期管控。

  • DeviceController+设备管理模块(DeviceTwin): 把设备管理能力直接集成到EdgeCore中,为用户提供原生的设备管理能力。

上述的架构设计,对比Kubernetes的能力增强点主要有:

  • **边缘自治:**通过增加节点元数据缓存,可以规避云边断网状态下,边缘业务或者节点重启时,边缘组件可以利用本地缓存数据进行业务恢复,这就带来了边缘自治的好处。

  • 轻量化: 削减了部分kubelet功能(如CSI,CNI等),从而使边缘EdgeCore组件相比原生kubelet组件更加轻量。同时因为节点上增加了SQLite数据库,所以节点维度相比原生节点是否轻量待确认,欢迎熟悉的同学提供数据。

架构差异可能带来的影响:

  • 云原生生态兼容性不足:

  1. 跟随社区同步演进挑战大: 由于对Kubernetes系统的侵入式修改,后续跟随Kubernetes社区的演进将会遇到很大挑战。

  2. 边缘节点无法运行Operator:因为云边通信机制的修改,Cloud Hub只能往边缘推送有限的几种资源(如Pod,ConfigMap等)。而Operator既需要自定义CRD资源,又需要list/watch云端获取关联资源,因此社区的Operator无法运行的KubeEdge的边缘节点上。

  3. 边缘节点不适合运行需要list/watch云端的应用: 因为云边通信机制的修改,导致原来需要使用list/watch机制访问kube-apiserver的应用,都无法通过hub tunnel 通道访问kube-apiserver,导致云原生的能力在边缘侧大打折扣。

  • 运维监控能力支持有限:因为目前云边通信链路是kube-apiserver --> controller --> Cloud Hub -->EdgeHub -->MetaManager等,而原生Kubernetes运维操作(如kubectl proxy/logs/exec/port-forward/attch等)是kube-apiserver直接请求kubelet。目前KubeEdge社区最新版本也仅支持kubectl logs/exec/metric,其他运维操作目前还不支持。

  • 系统稳定性提升待确定:

  1. 基于增量数据的云边推送模式:可以解决边缘watch失败时的重新全量list从而引发的kube-apiserver 压力问题,相比原生Kubernetes架构可以提升系统稳定性。

  2. Infra管控数据和业务管控数据耦合:Kubernetes集群的管控数据(如Pod,ConfigMap数据)和边缘业务数据(设备管控数据)使用同一条websocket链路,如果边缘管理大量设备或者设备更新频率过高,大量的业务数据将可能影响到集群的正常管控,从而可能降低系统的稳定性。

边缘计算场景支持能力

  • 设备管理能力: 这个能力直接集成在edged中,给iot用户提供了一定的原生设备管理能力。

2.2OpenYurt

(1)开源状况

OpenYurt是阿里云于2020年5月份开源的,目前是CNCF沙箱项目。架构如下:

计算机教育中缺失的一课 · the missing semester of your cs education

(2)与Kubernetes的架构差异

OpenYurt的架构设计比较简洁,采用的是无侵入式对Kubernetes进行增强。在云端(K8s Master)上增加Yurt Controller Manager, Yurt App Manager以及Tunnel Server组件。而在边缘端(K8s Worker)上增加了YurtHub和Tunnel Agent组件。从架构上看主要增加了如下能力来适配边缘场景:

  • YurtHub: 代理各个边缘组件到K8s Master的通信请求,同时把请求返回的元数据持久化在节点磁盘。当云边网络不稳定时,则利用本地磁盘数据来用于边缘业务的生命周期管控。同时云端的Yurt Controller Manager会管控边缘业务Pod的驱逐策略。

  • Tunnel Server/Tunnel Agent: 每个边缘节点上的Tunnel Agent将主动与云端Tunnel Server建立双向认证的加密的gRPC连接,同时云端将通过此连接访问到边缘节点及其资源。

  • Yurt App Manager:引入的两个CRD资源: NodePool 和 UnitedDeployment. 前者为位于同一区域的节点提供批量管理方法。后者定义了一种新的边缘应用模型以节点池维度来管理工作负载。

上述的架构设计,对比Kubernetes的能力增强点主要有:

  • 边缘单元化:通过Yurt App Manager组件,从单元化的视角,管理分散在不同地域的边缘资源,并对各地域单元内的业务提供独立的生命周期管理,升级,扩缩容,流量闭环等能力。且业务无需进行任何适配或改造。

  • 边缘自治: 因为每个边缘节点增加了具备缓存能力的透明代理YurtHub,从而可以保障云边网络断开,如果节点或者业务重启时,可以利用本地缓存数据恢复业务。

  • 云边协同(运维监控):通过Tunnel Server/Tunnel Agent的配合,为位于防火墙内部的边缘节点提供安全的云边双向认证的加密通道,即使边到云网络单向连通的边缘计算场景下,用户仍可运行原生kubernetes运维命令(如kubectl proxy/logs/exec/port-forward/attach等)。同时中心式的运维监控系统(如prometheus, metrics-server等)也可以通过云边通道获取到边缘的监控数据。

  • 云原生生态兼容:

  1. 所有功能均是通过Addon或者controller形式来增强Kubernetes,因此保证来对Kubernetes以及云原生社区生态的100%兼容。

  2. 另外值得一提的是:OpenYurt项目还提供了一个YurtCtl工具,可以用于原生Kubernetes和OpenYurt集群的一键式转换,

架构差异可能带来的影响

  • 原生Kubernetes带来的系统稳定性挑战:因为OpenYurt没有修改Kubernetes,所以这个问题也是原生Kubernetes在边缘场景下的问题。当云边长时间断网再次恢复时,边缘到云端会产生大量的全量List请求,从而对kube-apiserver造成比较大的压力。边缘节点过多时,将会给系统稳定性带来不小的挑战。

  • 边缘无轻量化解决方案: 虽然OpenYurt没有修改Kubernets,但是在边缘节点上增加YurtHub和Tunnel Agent组件。目前在最小的1C1G的系统上运行成功,更小规格机器待验证。

边缘计算场景

  • 无设备管理能力:OpenYurt目前没有提供设备管理的相关能力,需要用户以workload形式来运行自己的设备管理解决方案。虽然不算是架构设计的缺点,但是也算是一个边缘场景的不足点。

2.3.SuperEdge

(1)开源状况

SuperEdge是腾讯云于2020年12月底开源的,目前还是开源初期阶段。其架构如下:

在国企当程序员是怎么样的体验?

(2)与Kubernetes的架构差异

SuperEdge的架构设计比较简洁,也是采用的无侵入式对Kubernetes进行增强。在云端(K8s Master)上增加Application-Grid Controller, Edge-Health Admission以及Tunnel Cloud组件。而在边缘端(K8s Worker)上增加了Lite-Apiserver和Tunnel Edge,Application-Grid Wrapper组件。从架构上看主要增加了如下能力来适配边缘场景:

  • Lite-Apiserver: 代理各个边缘组件到K8s Master的通信请求,同时把请求返回的元数据持久化在节点磁盘。当云边网络不稳定时,则利用本地磁盘数据来用于边缘业务的生命周期管控。同时基于边缘Edge-Health上报信息,云端的Edge-Health Admission会管控边缘业务Pod的驱逐策略。

  • Tunnel Cloud/Tunnel Edge: 每个边缘节点上的Tunnel Edge将主动与云端Tunnel Cloud建立双向认证的加密的gRPC连接,同时云端将通过此连接访问到边缘节点及其资源。

  • Application-Grid Controller:引入的两个CRD资源: ServiceGrids和 DeploymentGrids. 前者为位于同一区域的业务流量提供闭环管理。后者定义了一种新的边缘应用模型以节点池为单位来管理工作负载。

与OpenYurt对比

  • 从SuperEdge的架构以及功能分析下来,发现SuperEdge从架构到功能和OpenYurt基本一致。这也从侧面印证,边缘计算云原生这个领域,各大厂商都在如火如荼的投入。

  • SuperEdge与Kubernetes的对比分析可以参照OpenYurt的分析,这里我们从代码角度分析SuperEdge和OpenYurt的差异:

  • YurtHub和Lite-Apiserver: YurtHub采取了完善的证书管理机制和本地数据缓存设计,而Lite-Apiserver使用的是节点kubelet证书和数据简单缓存。

  • Tunnel组件:OpenYurt的Tunnel组件是基于Kubernetes社区的开源项目ANP,同时实现了完善的证书管理机制。而SuperEdge的Tunnel组件同样也是使用节点证书,同时请求转发是基于自行封装的gRPC连接。OpenYurt底层的ANP相比原生gRPC,会更好适配kube-apiserver的演进。

  • 单元化管理组件: OpenYurt单元化管理支持Deployment和StatefulSet,而SuperEdge的单元化管理只支持Deployment。另外OpenYurt的NodePool和UnitedDeployment的API定义是标准云原生的设计思路,而SuperEdge的ServiceGrids和 DeploymentGrids的API定义显得随意一些。

  • 边缘状态检测,这个能力OpenYurt未实现,SuperEdge的设计需要kubelet监听节点地址用于节点间互相访问,有一定安全风险。同时东西向流量也有不少消耗在健康检查上。期待这个部分后续的优化。

5. 对比结果一览

根据上述的对比分析,结果整理如下表所示:

项目华为KubeEdge阿里OpenYurt腾讯SuperEdge
是否CNCF项目是(孵化项目)是(沙箱项目)
开源时间2018.112020.52020.12
侵入式修改Kubernetes
和Kubernetes无缝转换未知
边缘自治能力有(无边缘健康检测能力)有(无边缘健康检测能力)有(安全及流量消耗待优化)
边缘单元化不支持支持支持(只支持Deployment)
是否轻量化是(节点维度待确认)
原生运维监控能力部分支持全量支持全量支持(证书管理及连接管理待优化)
云原生生态兼容部分兼容完整兼容完整兼容
系统稳定性挑战大(接入设备数量过多)大(大规模节点并且云边长时间断网恢复)大(大规模节点并且云边长时间断网恢复)
设备管理能力有(有管控流量和业务流量耦合问题)

3. 总结

各个开源项目,整个比较下来自己的感受是:KubeEdge和OpenYurt/SuperEdge的架构设计差异比较大,相比而言OpenYurt/SuperEdge的架构设计更优雅一些。而OpenYurt和SuperEdge架构设计相似,SuperEdge的开源时间晚于OpenYurt,项目成熟度稍差。

如果打算选择一个边缘计算云原生项目用于生产,我会从以下角度考虑:

  • 如果需要内置设备管理能力,而对云原生生态兼容性不在意,建议选择KubeEdge

  • 如果从云原生生态兼容和项目成熟度考虑,而不需要设备管理能力或者可以自建设备管理能力,建议选择OpenYurt

往期推荐

水货CTO,将熊熊一窝

职场异性相处PPT!网友:你倒是给我分配个女同事啊!

如何使错误日志更加方便排查问题

Spring Boot 2.x基础教程:使用MongoDB

用了10年的微信表情,它居然偷偷把烟给戒了...

如果你喜欢本文,欢迎关注我,订阅更多精彩内容

关注我回复「加群」,加入Spring技术交流群

⚔ 这些葵花宝典,无须自宫,免费领取  

点击领取:大佬的SQL基础知识PDF

喜欢的这里报道

↘↘↘

  • 0
    点赞
  • 0
    评论
  • 1
    收藏
  • 一键三连
    一键三连
  • 扫一扫,分享海报

©️2021 CSDN 皮肤主题: 像素格子 设计师:CSDN官方博客 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值