下面我们一起来学习KubeEdge的架构设计。
首先我们来了解一下KubeEdge的背景,KubeEdge是华为开源的,在2019年捐赠给了CNCF基金会,目前源代码在github上面托管,
是作为云原生基金会孵化的首个边缘计算的产品,目前正处于孵化当中。
下面我们来看一下KubeEdge的logo,
我们看一下它的logo像一种什么生物?
logo非常的像章鱼,之所以类比就是章鱼在围捕狩猎的时候,比如说用它的触角去抓一些小鱼小虾,然后它们触角之间会高度的配合,它们会不会因为在抓鱼的时候自己把自己给缠绕起来?
是不会的,是因为章鱼 40% 的神经元分布在它的头部,然后60%的神经元分在它的这些触角上面,所以说它是一个多个小脑,一个大脑构成了一个分布式计算的系统,而我们这个边缘计算和它真的非常的像,我们边缘计算也是一种分布式的计算,这种分布式的好处就是我们大部分这些重复的低级的操作,我们这个触角也就是我们的边缘侧来完成,而云端就处理一些核心的这些数据,从而减轻了云端的这些功耗。
下面我们就来看一下KubeEdge的架构设计图,看看是不是这种思想去设计的,这是KubeEdge的架构设计图,
了解KubeEdge的架构设计,对我们后续不管是使用KubeEdge,还是看它的实现源码都会非常的有帮助,KubeEdge的模块还是比较多的,我们可以从这个架构图可以看出,我这里将架构图拆分为三个部分来说,
第一个就是我们云边的通信方式,
第二个就是云端的架构设计,
第三部分就是边缘端的架构设计。
下面我们就来看一下云边的通信方式,从架构设计图可以看出在云端对应的 Cloud Hub 模块,以及边缘端的 Edge Hub 模块,它们之间是双向通信的,【websocket协议】然后其中Cloud Hub和 Edge Hub,它们就分别承担着云端和边缘端的网络代理的工作。现在就是说云端和边缘端的流量的出入都会经由此处,然后它们之间的通信方式就是微websocket协议,
其中云端就是websocket的服务端,运营端就是websocket的客户端,为什么要采用这种方式,难道HTTP不香吗?原因是因为HTTP只能由客户端向服务端发起请求,就类似于我们这种Restful API的风格的发送一些GET POST 或者是PUT DELETE 这种请求。而在云边协同的这种场景下,很多时候需要云端主动的向边缘端发起请求,而websocket刚好就能解决这个问题。
那么接下来的问题就是云边通信,通信的内容是什么?
我这里将通信的数据分成了两个类别,就是配置数据和我们业务数据。
那么配置数据包括哪些?在云边协同的场景下,我们需要由云端向边缘端下发应用,因为应用都是以pod的方式运行的,所以说我们可以理解为云端向边缘端发送创建pod的指令,而这种创建pod的指令的数据就是要通过这种websocket完成下发的,同时边缘端布置pod完毕之后,边缘端还需要实时向云端上报 pod 的运行状态,以及它的运行的一些日志信息。由于这些数据适用于配置 我们这个业务,是一些底层的技术支撑的,
所以说我把它称之为是配置数据。
那么有配置数据对应的就是一些业务数据,从架构设计图当中可以看到,
这边有一个APP和MQTT两个部分,这两种方式的话就是边缘端接入设备的这种方式,接入之后就可以通过这两种方式与我们云端做数据的交互,而这里交互的数据就是与我们业务相关的一些数据,所以说称之为就是业务数据。
有关这两种数据交互的方式,这边有一个EventBus和ServiceBus,
然后就是云边的它一个通信方式的内容。
关注我,为思考点赞!