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。