其他分享
首页 > 其他分享> > KubeEdge架构问题汇总

KubeEdge架构问题汇总

作者:互联网

Q1 :KubeEdge云和边的数据协同有什么优势?

A :  K8s的原生架构中, Node (Kubelet) 是通过List-watch机制主动与Master通信。List-watch机制有几个特点:1.事件传输没有ACK类的校验机制,要依赖数据中心稳定的网络保证不丢事件 2. 每次网络断开,Node侧都会从新执行List操作(取回所有数据),要依赖数据中心稳定的网络保证长连接不频繁断开,否则对Master及网络都是很大的损耗。

 

在边缘场景下,众所周知网络都是很不稳定的,包括丢失数据、连接断开等。针对不稳定的网络,在KubeEdge云边协同的设计中:

  1. 我们把List-watch中的事件取出来,加了ACK校验机制,只有边缘收到数据且回复ACK信息,云端才认为发送成功,反之则进行重试。

  2. 在网络断开(确认节点离线)后,云端会将待同步数据持久化,等到边缘节点上线,再将缓存的待发送数据逐一下发。

  3. 针对未发送的消息实时检查合并去重,避免网络震荡。

 

KubeEdge的云边协同机制不仅保证了云和边之间数据的可靠传输,也避免了网络不稳定时重新List造成的网络压力。

 

 

Q2 KubeEdge目前是如何解决边缘节点自治能力的?

A :  KubeEdge会边缘将收到的应用、设备元数据都进行本地持久化。相比Kubelet在内存中缓存对象的方式,可以有效保证节点离线、故障恢复时的业务自治和快速自愈。

 

 

Q3 :边缘节点离线后,依赖数据多次变更,边缘应用和云端数据的最终一致是怎么保证的?

:  KubeEdge目前的应用管理等操作都需要通过K8s master进行,针对边缘节点离线场景主要提供自治的能力,即本地持久化的数据仅用于管理节点上的应用和设备,云边通信恢复时,节点将同步云依据来自CloudCore的最新消息更新本地元数据。这里稍有不同的是边缘设备管理,对设备期望状态的设置需要通过Device CRD中的Desired State来操作(从云到边),而设备实际状态的上报会体现在Reported State中(从边到云),两个方向的数据同步不会冲突。

 

 

Q4 KubeEdgeK3s的区别是什么?

  首先是架构选型问题,K3s选择的是在边缘运行整个K8s集群的方案,不具备云边协同的能力;其次K3s虽然对K8s做了轻量化,但整体资源要求仍然较高,无法运行在IOT Hub、工业网关等小型设备中。

 

KubeEdge针对边缘场景的优化包括:

  1. 针对边缘网络不稳定的情况,增加了云边数据协同的可靠性传输、边缘元数据持久化,减少了网络不稳定造成的压力震荡,实现了边缘离线自治的能力,在云边断联、节点故障恢复时保证业务不受影响。

  2. 针对边缘资源不足的情况,对Kubelet进行轻量化裁剪,支持在256MB的设备上运行。

  3. 针对复杂多样的边缘设备管理,KubeEdge定义了一套通用的设备管理API(K8s CRD)以及设备协议解耦层,用户可以方便地使用KubeEdge进行管理各种边缘设备。

 

 

Q5 :中心K8s对边缘节点的管理主要操作有哪些?

:  KubeEdge运行在K8s完整的应用调度、管理能力之上,意味着KubeEdge的云端不负责应用的调度、管理,只是将调度到边缘节点的应用、设备元数据下发到边缘。KubeEdge在云端的核心组件是CloudCore,包含EdgeController、DeviceController、CloudHub三个模块,EdgeController、DeviceController负责将应用、设备元数据下发到边缘,同时将来自边缘的节点状态、应用状态、设备状态刷新到K8s集群中;CloudHub负责直接与边缘通信。

 

 

Q6 :新版本边缘节点的service还是仅支持hostPort吗,nodeport是否支持?

从KubeEdge 1.1版本开始集成了CRI,意味着用户可以使用CNI插件来配置网络,不再限制于hostport。NodePort是K8s中服务访问的概念,需要通过Kube-proxy来配置,目前在边缘端还不支持。另外KubeEdge提供了EdgeMesh实现边缘应用间的互访

 

 

Q7 :边缘节点的Docker容器镜像是从整个云-k8s系统统一的镜像仓库拉取的吗?

只要边缘端能够访问到的镜像仓库,都能够用来拉取镜像

 

 

Q8 PPT里提到"KubeEdge 用于将容器化应用程序编排功能扩展到Edge的主机。"  那么,是把云上的应用下沉到edge、还把终端设备上的应用提升到edge呢?

KubeEdge作为应用管理平台时,可以在云端统一管控,既可以把应用部署到云端节点,也可以部署到边缘节点。用户可以根据自身需求,将云端的部分业务下沉到边缘。如果需要将终端设备上的应用部署到边缘节点,也可以通过KubeEdge来部署。

 

 

Q9 :边缘侧的各个应用是怎么通信的?比如一个做sql过滤的应用和另一个做数据分析的应用是通过hub统一转发的,还是应用间就同步了,亦是通过mqtt等协议?同步异步消息分别怎么实现的?

目前KubeEdge中使用EdgeMesh机制来做边缘端应用的互访,不需要通过hub与mqtt转发,在EdgeMesh实现应用互通的前提下,同步异步消息依赖用户应用自身的机制。

 

 

Q10 KubeEdge节点和普通节点都在 kubectl get node 中获取到,这两者有什么区别

没有本质区别,KubeEdge的边缘组件会将Node通过云边协同通道注册到K8s Master,唯一的不同是普通节点由Kubelet直接访问Master完成节点注册,KubeEdge是通过云边协同通道注册,API都是一致的。

 

 

Q11KubeEdge modbus协议是用什么设备调试的?

A目前开发调试中使用modbus slave来调试。

 

 

Q12 KubeEdge的安全层是怎么做的

KubeEdge云边协同使用了安全的WebSocket通道。对于应用间的安全互访要依赖用户自己配置安全证书等。

 

 

Q13 KubeEdge边缘节点能管理GPU设备吗?

边缘节点可以通过DevicePlugin来管理GPU设备。

 

标签:架构,云边,汇总,边缘,应用,KubeEdge,K8s,节点
来源: https://www.cnblogs.com/gongxianjin/p/15913375.html