KubeEdge边缘自治设计原理

时间:2024-01-28 20:53:55

这一篇内容主要是KubeEdge中边缘节点组件EdgeCore的原理介绍。

KubeEdge架构—EdgeCore

 

 上图中深蓝色的都是kubeedg自己实现的组件,亮蓝色是k8s社区原生组件。这篇主要内容是黄色框框的这三个组件。有一个值得注意的是,这些蓝色框的组件其实都是一个模块,都是在一个进程edgecore里的。

Module间通信

 

这里Process相当于EdgeCore,是一个进程,这个进程里面分为多个Module模块(EdgeHub、MetaManager、EdgeD)。

它们之间是通过一个BeehiveContext进行通信的,首先模块起来之后会在BeehiveContext中进行注册,每个模块会有一个对应的channel,这个channel是根据Modeule name放到一个map里面。加入模块B要给模块A发送消息,它就会根据模块A的名字将要发送的消息塞到对应的channel队列里,模块A一直在监听,有数据时就会去读出来。这就是一个进程里面Module间通信的原理。

ModeuleContext是模块注册相关接口

MessageContext是发送数据相关接口,比如send(module stirng,message model.Message)函数,第一个参数表示要发送给哪个模块,第二个message的类型和之前云边通信的message是同一种,也就是说kubeedge里面所有的通信包括云边协同的通信、进程间各个模块之间的通信,消息的结构都是统一的。

 

EdgeHub

edgehub是边缘节点用来收发数据的模块,与之相对应的是云端的cloudhub。

上行——通过EdgeHub刷新状态

 

 

上行的数据包括:edged管理的node、pod的状态信息,它先报到MetaManager这边,MetaManager在传到EdgeHub,经过edgehub把数据同步到云上。这样就实现了node、pod状态的上报。关于设备的信息这篇内容不纤细展开。

下行——通过EdgeHub下发元数据

 

这里的MessageDispatcher的作用和云上的有点区别:这个是分发到不同的模块,云上是分发到不同的边缘节点。如果是pod的元数据,就推给metamanager->Edged去拉起相应容器;如果是设备信息,就推给DeviceTwin->EventBus。

 

MetaManager

 

MetaManager的作用是在EdgeHub和Edged之间做持久化,它会把原数据先持久化,注意:这里如果持久化失败的话,它会重新存或者发送失败的消息给云端,直到持久化成功后才会把数据传到Edged等相应模块

EdgeD 

 

EdgeD是裁剪的轻量化kubelet,保留了应用生命周期管理的相关模块,去掉了一些不必要的东西,比如第三方存储这些在边缘暂时不需要的。这里也集成了CNI/CSI/CRI,现在CNI里的东西都放在CRI里面去调用了,所以从代码里面看不到CNI的东西。

MetaClient是EdgeD新加的东西,MetaClient是直接跟MetaManager通信的,原生的kubelet里面KubeClient是跟api-server通信的。这里改了以后呢EdgeD挂掉重启之后拿到的数据是通过MetaClient到MetaManager那边去数据库里去拿,原生的KubeClient会去从ApiServer里面去拿。

 

边缘自治原理

云边连接断开

 

第一种情况是 云边连接断开后,边缘业务可稳定运行。原生k8s中断连后,节点上的资源信息会被调度到其他节点。

还有一种情况是云边连接断开后,边缘节点重启。原生k8s中,kubelet拿到的数据是保存在内存中的,如果连接断开,节点重启后,内存缓存的东西就会丢失,服务不可恢复。在KubeEdge中,边缘节点重启后会从本地数据库中拿到相应数据进行服务恢复。

管理边缘的完整集群

 

 

目前边缘自治的特性只适合单节点,边缘集群的自治可能会在后续版本中支持,也是目前我想要做的方向。如果边缘资源充足的话可以跑K8s集群,如果不充足的话用KubeEdge支持的EdgeSite。