边缘计算云原生开源方案选型比较( 二 ) _边缘计算

轻量化: 削减了部分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组件。从架构上看主要增加了如下能力来适配边缘场景：