KubeEdge 云端架构设计

了解了云边通信的方式之后，紧接着我们一起来看一下云端的架构设计，

从这张架构设计图当中‍‍可以看出就是云端需要去监听k8s的API Server，然后用户也操作API Server，‍‍说明KubeEdge和我们 k8s去做联系的话，就通过这种监听k8s的API Server 的方式去完成的，‍‍而具体这部分它怎么去监听的，怎么去和KubeEdge配合工作的，‍‍我在后面会讲。‍‍

而我们现在要关注的就是CloudCore，就是我们KubeEdge云端的架构设计，然后其中它有两部分，第一部分就是Controllers，

第二部分就是CloudHub，

CloudHub我们通过云边通信方式已经知道了，它和 EdgeHub是对立的，‍‍

负责云端的一个网络代理，所以说现在我们就重点工作就要去放在Controllers上，它到底干了个什么事情。‍‍

从架构设计图我们可以看出，Controllers是又分了两个部分，EdgeController和DeviceController，下面我们来看一下这俩它们做了什么事情。‍‍

首先是EdgeController，我这边准备了一张图，‍‍这是从云到边的这样一个流向图，

从云到边是怎么流向的？‍‍用户他通过 Kubectl命令工具来操作 我们 K8S-Api-Server，然后EdgeController它监听K8S-Api-Server，‍‍它监听什么东西?
就是这个 pod 和configMap它的资源更新的状态，‍‍ta更新之后就会把ta的状态报给我们CloudHub，CloudHub就把它发到我们边缘端，就是EdgeCore，‍‍边缘端知道云端已经发生了新的指令了，就按照云端新的指令去执行。‍‍

比如说创建‍‍pod 删除 pod 更新pod的操作。‍‍这边有一个比较有意思的就是 Locates，‍‍

将 configMap和Secret调度到特定的一些节点上面去，为什么会出现这个情况呢？‍‍
我们这个边缘节点上，它有可能不会用到configMap和Secret的，那么ta不用的话，那这边就不会给它调到EdgeCore上面去，‍‍

就节省了传输的资源，然后我们就来看一下，从边到云，‍‍

既然从云到边完成了pod资源的一些下发了，从边到云也可能会有一些资源的上报，‍‍比如说我们 pod 运行它的内存不足了，磁盘不足，pod挂掉了，‍‍它就会要上报给我们云端，而云端就把这些资源又报给了EdgeController，EdgeController在调用 K8S-Api-Server，把 pod 资源给更新了。‍‍

我们从边到云，‍‍我这个节点ta用到了configMap或者Secret ，那就会请求Query【上图红色箭头所指】，
然后云到边的CloudHub这边的configMap更新的时候就会给它发到EdgeCore上面去，

然后或者是ta请求了，也会根据ta的位置给ta发到对应的节点上面去。‍‍

然后这就是EdgeController做的事情。‍‍

我们来总结一下，

从云到边， EdgeController它是完成去监听K8S-Api-Server，完成我们资源的下发，
从边到云，‍‍EdgeController它其实是完成了我们资源的上报，上报之后它就调用K8S-Api-Server上报提供的API‍‍，去完成我们资源状态的更新。‍‍

总结就是两点，第一个监听，第二个上报，这是EdgeController做的事情。‍‍说完了EdgeController，
下面我们来看一下另外一个DeviceController，DeviceController 它的实现思路和EdgeController大致是相似的。

然后我们先来看从云端到边缘端的这样一个流向图，

就是可以看到用户还是通过kubectl去操作K8S-Api-Server，但是它这边操作的资源对象有所差别，它操作的是device和device model，‍‍

这两个资源是KubeEdge利用k8s 的自定义资源，
然后这边当Downstream，

也是DeviceController的一部分，‍‍它会去监听 device model和 device的状态，

然后监听之后它干两个事情，‍‍第一个它把期望值和上报值发送到边缘端，但是它会选一些节点，‍‍说明我们 device 和 节点它是有绑定关系的，‍‍

然后他还做另外一个事情 就是去创建config maps，这两个其实说明一个问题，‍‍操作这两个其实说明 device它其实定义的就是一些字段信息，
它定义什么字段信息，‍‍定义就是desired 期望值和reported实际值这两个字段，

然后ta把这两个字段把它映射成config maps，‍‍我们就来理解一下期望值和实际值它们之间是怎么样一个联系?

比如说我们云端希望边缘端的室内温度给它调到23度，然后我们实际的边缘端，‍‍比如说有一次温度计，‍‍它会测出来温度是25度，那么实际值和期望值之间它就有一个差别，‍‍但是我们可以在边缘端又布置一些应用，比如说空调，我们把云端，根据云端上报的23度，‍‍然后在边缘端给它调成了23度，那么这样的话期望值和上报值就是一样的了，‍‍这就是对期望值和上报值的一个理解，这是云到边的一个过程。‍‍

下面我们看从边到云，‍‍

从边到云，我们刚才举的温度的例子，我们就上报了 上报值，‍‍比如说我们温度测出来是多少就是多少，比如说云端现在是期望值是 33度，‍‍但是我们边缘端实际它是24度，然后就给它上报到云端上面去，这时候云端看是24度，‍‍然后因为边缘端这边有相应的一些调温的设备，比如说空调把它实际又调到23度了，‍‍好，我们在在云端去调用，通过K8S-Api-Server去看，发现云端和边缘端一致了，‍‍我们就知道这个边缘端已经满足了我们云端下发的要求，

这是 DeviceController 做的事情。‍‍

我们总结一下，‍‍其实它本身监听的 和EdgeController也是一样的，监听k8s的资源，但是它监听的是 device model和 device，‍‍这两个是KubeEdge利用k8s的自定义资源，然后云端和边缘端去根据它们的字段来完成云边的协同。‍‍

到这里我们就把云端的EdgeController和DeviceController 它的实现流程就学完了，我们就再来总结一下。‍‍

EdgeController和DeviceController 它们都是去调用K8S-Api-Server上面提供的API去监听对应的资源，它们监听资源的对象不一样，‍‍ EdgeController这边它主要是 pod configmap，‍‍然后DeviceController，它主要是监听KubeEdge自定义的资源device和device model，然后通过去监听这两个资源，‍‍对应的云端和边缘端之间会建立这些资源的状态，保持一致的这样的联系，‍‍然后这个是云端做的事情，这是KubeEdge云端的架构设计。‍

关注我，为思考点赞！