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

随着kubernetes已经成为容器编排和调度的事实标准，各大公有云厂商都已经基于kubernetes提供了完善的kubernetes云上托管服务。同时也看到越来越多的企业、行业开始在生产中使用kubernetes, 拥抱云原生。在各行各业数字化转型和上云过程中，公有云厂商也在主动拥抱传统线下环境，在思考各种各样的解决方案使云上能力向边缘(或线下)延伸。
而kubernetes由于屏蔽了底层架构的差异性，可以帮助应用平滑地运行在不同的基础设施上的特性，云上的kubernetes服务也在考虑拓展其服务边界，云原生和边缘计算结合的想法自然就呼之欲出了。
目前国内各个公有云厂商也都开源了各自基于kubernetes的边缘计算云原生项目。如华为云的kubeedge，阿里云的openyurt，腾讯云的superedge。目前网上很少有从技术视角来介绍这几个项目优缺点的文章，本文试着从技术视角，从开源视角来分析这几个项目，希望可以给大家做项目选型时提供一些借鉴。
01比较思路
这几个项目都是云边一体，云边协同的架构，走的是kubernetes和边缘计算结合的路数，因此决定从以下几点比较:
(1) 各个项目的开源状况：比如开源项目的背景、开源的时间、是否进入了cncf等;
(2)kubernetes架构:
先对比与kubernetees的架构差异：主要关注是否修改kubernetes，和;kubernetes一键式转换等
根据架构差异对比和kubernetes的能力增强点;主要关注边缘自治，边缘单元化，轻量化等能力
最后看一下架构差异可能带来的影响: 主要关注运维监控能力，云原生生态兼容性，系统稳定性等方面
(3)对边缘计算场景支持能力:
主要关注是否具备端设备的管理能力
接下来以项目的开源顺序，从上述几个方面来介绍各个项目。
02边缘云原生开源项目对比
2.1kubeedge
(1)开源状况
kubeedge是华为云于2018年11月份开源的，目前是cncf孵化项目。其架构如下:
(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数据库，所以节点维度相比原生节点是否轻量待确认，欢迎熟悉的同学提供数据。
架构差异可能带来的影响：
云原生生态兼容性不足：
跟随社区同步演进挑战大: 由于对kubernetes系统的侵入式修改，后续跟随kubernetes社区的演进将会遇到很大挑战。
边缘节点无法运行operator：因为云边通信机制的修改，cloud hub只能往边缘推送有限的几种资源(如pod，configmap等)。而operator既需要自定义crd资源，又需要list/watch云端获取关联资源，因此社区的operator无法运行的kubeedge的边缘节点上。
边缘节点不适合运行需要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，其他运维操作目前还不支持。
系统稳定性提升待确定:
基于增量数据的云边推送模式：可以解决边缘watch失败时的重新全量list从而引发的kube-apiserver 压力问题，相比原生kubernetes架构可以提升系统稳定性。
infra管控数据和业务管控数据耦合：kubernetes集群的管控数据(如pod，configmap数据)和边缘业务数据(设备管控数据)使用同一条websocket链路，如果边缘管理大量设备或者设备更新频率过高，大量的业务数据将可能影响到集群的正常管控，从而可能降低系统的稳定性。
边缘计算场景支持能力
设备管理能力: 这个能力直接集成在edged中，给iot用户提供了一定的原生设备管理能力。
2.2openyurt
(1)开源状况
openyurt是阿里云于2020年5月份开源的，目前是cncf沙箱项目。架构如下:
(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等)也可以通过云边通道获取到边缘的监控数据。
云原生生态兼容:
所有功能均是通过addon或者controller形式来增强kubernetes，因此保证来对kubernetes以及云原生社区生态的100%兼容。
另外值得一提的是：openyurt项目还提供了一个yurtctl工具，可以用于原生kubernetes和openyurt集群的一键式转换，
架构差异可能带来的影响
原生kubernetes带来的系统稳定性挑战：因为openyurt没有修改kubernetes，所以这个问题也是原生kubernetes在边缘场景下的问题。当云边长时间断网再次恢复时，边缘到云端会产生大量的全量list请求，从而对kube-apiserver造成比较大的压力。边缘节点过多时，将会给系统稳定性带来不小的挑战。
边缘无轻量化解决方案: 虽然openyurt没有修改kubernets，但是在边缘节点上增加yurthub和tunnel agent组件。目前在最小的1c1g的系统上运行成功，更小规格机器待验证。
边缘计算场景
无设备管理能力：openyurt目前没有提供设备管理的相关能力，需要用户以workload形式来运行自己的设备管理解决方案。虽然不算是架构设计的缺点，但是也算是一个边缘场景的不足点。
2.3superedge
(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(github.com/kubernetes-s)，同时实现了完善的证书管理机制。而superedge的tunnel组件同样也是使用节点证书，同时请求转发是基于自行封装的grpc连接。openyurt底层的anp相比原生grpc，会更好适配kube-apiserver的演进。
单元化管理组件: openyurt单元化管理支持deployment和statefulset,而superedge的单元化管理只支持deployment。另外openyurt的nodepool和uniteddeployment的api定义是标准云原生的设计思路，而superedge的servicegrids和 deploymentgrids的api定义显得随意一些。
边缘状态检测，这个能力openyurt未实现，superedge的设计需要kubelet监听节点地址用于节点间互相访问，有一定安全风险。同时东西向流量也有不少消耗在健康检查上。期待这个部分后续的优化。
2.4对比结果一览
根据上述的对比分析，结果整理如下表所示：
03总结
各个开源项目，整个比较下来自己的感受是：
kubeedge和openyurt/superedge的架构设计差异比较大，相比而言openyurt/superedge的架构设计更优雅一些。而openyurt和superedge架构设计相似，superedge的开源时间晚于openyurt，项目成熟度稍差。
如果打算选择一个边缘计算云原生项目用于生产，我会从以下角度考虑：
如果需要内置设备管理能力，而对云原生生态兼容性不在意，建议选择kubeedge
如果从云原生生态兼容和项目成熟度考虑，而不需要设备管理能力或者可以自建设备管理能力，建议选择openyurt


SEO优化公司怎么选择适合自己的？
白帽SEO、黑帽SEO、灰帽SEO你真的了解吗?
如何让网站关键词排名更加稳定呢？
网站开发比得是耐心
cn2线路的香港云服务器性能怎么样?
微信公众平台自定义菜单创建接口
个人网站该怎么发展盈利吗？
呼和浩特网站优化：影楼行业网络推广五步曲