KubeEdge：如何在云端点亮您家的灯 的相关思考

KubeEdge：如何在云端点亮您家的灯

的相关思考 

• 边缘计算与KubeEdge

云计算离终端设备（如摄像头、传感器等）较远，对于实时性要求高的计算需求，把计算放在云上会引起较长的网络延时、网络拥塞、服务质量下降等问题。而终端设备通常计算能力不足，无法与云端相比。在此情况下，边缘计算应运而生，将云端计算能力延伸到靠近终端设备的边缘节点，完美解决上述问题。

KubeEdge作为全球首个Kubernetes原生的开源边缘计算平台，依托Kubernetes的容器编排和调度能力，通过纳管用户的边缘节点，提供将云上应用延伸到边缘的能力，联动边缘侧和云端的数据，满足客户对边缘计算资源的远程管控、数据处理、分析决策、智能化的诉求。同时，在云端提供统一的设备/应用监控、日志采集等运维能力，为企业提供完整的边云协同一体化服务的边缘计算解决方案。

• 设备孪生与kubeEdge设备管理

设备孪生Device twin,作为一种IoT设备元数据在应用平台上的映射，已经成为IoT设备管理的重要组成。
这大概解决我对云端如何管理边缘设备的困扰。

IoT设备元数据分为静态属性（序列号、资产标示符、mac地址等）和动态属性（特定背景下的实时数据）动态属性也成为Twin属性。

设备孪生和物理设备具有相同的特性，便于设备与应用之间进行更好的通信。

思考，设备孪生是位于云端，k8s管理设备孪生的状态，而设备孪生真正控制物理设备，这其实相当加了一层虚拟，好似软件定义的设备。

设备孪生维护这期望值和实际值，期望值是远端下达的命令结果，实际值是从物理设备更新到的数据，设备孪生像物理设备发送控制命令，使两个状态最终一致。

从这张图，可以看到设备孪生的两个状态属性，以及和物理设备之间的关系。IoT设备实时反馈自己的actual state到其孪生设备上，孪生设备根据其期望值向IoT设备发送期望状态，IoT收到Expected State后，更新自己的状态。

有个疑问，将IoT设备纳入云端管理的意义是什么？
原来认为IoT设备就是被一个远程服务器在处理控制的，比较像一个单一的服务器，现在看起来通过容器云管理，粒度细了，各服务进程相对对立，资源隔离。有点感觉像从虚拟机到容器的状态。

这样看来，容器中实际运行的应该IoT的设备孪生，及是它的远程服务，用户端app是和设备孪生通信，设备孪生和IoT设备交换数据。
设备孪生就是从原来复杂的后台服务编程器了独立服务进程。如下图，描述kubeEdge的一个架构及数据流通状态。

• KubeEdge设备管理组件

相比k8s，kubeEdge变成了专用系统，增加了
EdgeController:管理云端及云端与边缘册设备的同步；
Cloudhub:web socket服务端，负责监听云端资源变化，缓存消息到EdgerHub;
EdgeHub:websocket客户端，包括同步云端资源更新，报告边缘节点和设备信息到云端等；
DeviceTwin:负责存储设备状态并同步到云端。
EventBus: 与MQTT服务器Mosquitto交互的客户端，为其他组件提供订阅和发布消息的功能。
Mapper(sdk/app):用于连接和控制端侧设备，例如开、关灯。

KubeEdge通过CRD（Customer Resource Definition）扩展Kubernetes的API，扩展的API资源包括：Device和DeviceModel等，这样我们能在云端通过Kubernetes命令行工具Kubectl或其他方式对设备资源进行CRUD的操作。Device资源映射与各个边缘节点关联的设备，例如传感器。DeviceModel则是对一类设备定义的模板，方便用户可以在云端依据DeviceModel模板轻易地完成对Device资源的批量操作。

CRD是k8s的一个功能，实现自定义资源到k8s api中，所以这样来说kubeEdge其实是对k8s的一个高层次的应用。

• 如何点亮家里的灯

hw举了一个例子，下图是设备孪生的属性状态，主要是两个属性，即实际状态和期望状态。下图就像k8s资源对象的配置文件。

开关灯流程，见下图。

图中分成了两个层次，一个云端一个边缘，这就跟上边所理解的设备孪生放在docker里作为独立的服务处理请求，应该是层次的划分，就像master和node节点的划分,下边一段话引用自kubeEdge的github的readme,注意edge node,应该印证了上边的思路。

Note: Currently, for edge node, we must use hostPort in the Pod container spec so that the pod comes up normally, or the pod will be always in ContainerCreating status. The hostPort must be equal to containerPort and can not be 0.

先看下，怎么开关电灯的。

首先我们看看如何上报灯的powerstatus的actual值到云端：

1. Mapper实时上报实际状态Actual State给MQTT服务器Mosquitto。
2. EventBus从Mosquitto收到订阅消息，消息内容包含设备的实际状态Actual State。
3. EventBus把设备实际状态Actual State发送给Device Twin。
4. Device Twin更新设备实际状态Actual State到边缘节点本地的轻量级数据库，例如SQLite。
5. Device Twin同步实际状态Actual State给WebSocket客户端EdgeHub。
6. EdgeHub发送消息给WebSocket服务端CloudHub。
7. CloudHub回馈消息给DeviceController。
8. DeviceController同步实际状态Actual State到Kubernetes API Server。

最后用户就能在云端查询设备的powerstatus的actual值，获取到边缘侧设备上的灯开、关的实际状态。

这里为自己强调一下，mapper，即sdk/app，其实是物理设备，由于edge node上运行的是设备孪生，所以用户app应该不是直接访问/控制数据的，而应从专门的服务（该服务可能也部署在k8s上，甚者和设备孪生在同一个物理node上）上获得处理，并更新到设备孪生上。

云端控制，主要是服务处理吧，像丰巢、贩卖机、路灯等等需要商业维护的物联网，而不像是自己一直带入的智能家居类的IoT。

k8s为自己带来了一个新的容器云世界，kubeEdge又带来了一个不一样的IoT云端管理的思路。

• 参考

1. 文章来自 华为容器魔方 KubeEdge：如何在云端点亮您家的灯
2. kubeEdge项目