KubeEdge边缘自治设计原理

这一篇内容主要是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。