「连载」边缘计算（五）01-22：边缘部分原理解析（原理篇）

（接上篇）

云边协同

云边协同机制是边缘计算系统边部分解决方案KubeEdge的关键。有了该机制，KubeEdge便可以适应边缘恶劣的网络环境，即在边缘节点与云失去联系时，边缘节点也可以独立工作，不影响边缘已有负载的正常运行。KubeEdge中的云边协同架构如图5-5所示。

图5-5 KubeEdge中的云边协同架构

由图5-5可知，云边协同涉及KubeEdge的云、边、端三部分，但主要工作由KubeEdge的EdgeCore组件来完成。云边协同是由EdgeCore中的MetaManager、DeviceTwin和Edgemsh三个功能模块共同完成的。各模块的具体功能和达到的效果如下。

1）MetaManager：负责将从云接收到的pod、ConfigMap、Secret、Service、和Endpoint等资源的增、删、改、查信息写入sqlite。当边缘节点和云之间的网络断开时，Edged在需要相关资源数据时，可以通过MetaManager从sqlite中读取，从而保障边缘节点上原有应用负载的正常运行。

2）DeviceTwin：负责将从云接收到的DeviceInstance、DeviceTwin和Desired等资源的增、删、改、查信息写入sqlite，在边缘节点和云之间的网络断开时，EventBus可以通过DeviceTwin从sqlite中读取，从而保障终端设备的正常运行。

3）Edgemsh：将从云下发到边缘的Service资源数据转换为DNS记录存在边缘节点，在边缘节点和云之间的网络断开时，运行在边缘节点的负载也可以通过访问域名实现同一节点上的pod间的通信和在不同节点上的pod间的通信，从而保障边缘节点上原有应用负载的正常运行。

设备管理模型

设备管理模型是在Kubernetes已有的资源管理模型的基础上，增加的管理设备资源的模型和组件。本节将从设备资源管理模型和设备资源管理流程两个维度对其进行系统梳理和分析，具体如图5-6所示。

 图5-6 KubeEdge设备资源管理模型

由图5-6可知，KubeEdge要实现对设备资源的管理，需要通过Kubernetes的客户资源定义CRD(Custom Resource Definiton)添加与设备相关的客户资源定义CRD，包括Device Model和Device，并添加管理相应控制器，包括Device Controller。它们的具体功能如下。

1）Device Model：设备模板的抽象，定义了设备的一些通用属性包括设备元数据、各项元数据的要求、设备规格、各项设备规格的要求。

2）Device：设备实例的定义，包含了设备实例元数据各项的具体值和设备规格各项的具体值。

3）Device Controller：在云上监听与设备相关的DeviceInstance、DeviceTwin和Desired等资源的增、删、改、查信息，并从云上下发到边缘，接收边缘上报到云的设备相关的 DeviceStatus、DeviceTwin和Reported等事件，并对其进行相应处理。

由图5-7可知，在KubeEdge中对设备资源的管理横跨了KubeEdge中的云、边、端三部分。在整个设备资源的管理流程中，KubeEdge中的云、边、端三部分所做的具体工作如下。

1）在云上首先需要创建设备相关的资源，即Device Model和Device，这样终端的设备才能够正常注册，在云上才能够对已经注册的设备进行正常的管理。

2）在云上工作就绪的基础上，在边缘上的DeviceTwin功能模块会将从云下发到边缘的关于设备资源定义进行本地化存储，同时将终端上报的设备状态也在边缘进行本地化存储，这样在云与边缘断网时，终端设备也可以正常工作。

3）在云和边缘上工作就绪的基础上，终端设备就可以进行正常的注册，接收云上对终端下发的管理指令，并将终端设备的状态数据上报。

图5-7 KubeEdge设备资源管理流程

 「未完待续……」

点击下方标题可阅读技术文章

「连载」边缘计算（一）01-16：边缘计算系统逻辑架构（原理篇）
「连载」边缘计算（二）01-17：边缘计算系统逻辑架构（原理篇）
「连载」边缘计算（三）01-18：边缘部分原理解析（原理篇）

「连载」边缘计算（四）01-19：边缘部分原理解析（原理篇）