架构差异可能带来的影响

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

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用户提供了一定的原生设备管理能力。

（编辑：上饶站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!