主要组件

云端

以下3个都是Module，均运行在cloudcore进程中。

CloudHub

a web socket server responsible for watching changes at the cloud side，caching and sending messages to EdgeHub.

CloudHub作为云到边的网络信道，支持多种协议（websocket/QUIC，边侧可选择其中一种和CloudHub进行通信）

EdgeController

an extended kubernetes controller which manages edge nodes and pods metadata so that the data can be targeted to a specific edge node.

EdgeController负责管理边缘节点和pod的metadata。

DeviceController

an extended kubernetes controller which manages devices so that the device metadata/status data can be synced between edge and cloud.

DeviceController负责管理设备的metadata和status信息。

这里来详细看一下DeviceController：device controller负责边缘设备管理，通过k8s的Custom Resource Definition（CRDs）来描述设备的元信息和状态信息，并在云和边之间传递这些信息。Device controller在实现上主要通过2个goroutines：uptream controller和downstream controller。

• downstream controller：通过watch on k8s API server，将设备信息从云同步到边。
• upstream controller：将device updates通过device twin同步给云端。

下图描述了kubeedge是如何通过CRDs来管理设备：

下图描述了upstream模块的简化流程：

下图描述了upstream模块的详细流程，从图中可以看到，端设备通过mqtt broker，将设备信息上报给Edge/EventBus，EventBus会将信息提供给DeviceTwin，DeviceTwin将其保存到数据库中，并同步一份到EdgeHub，从而将信息同步给云端。

在云端，device controller通过k8s API将设备信息存储起来，再通过downstream模块下发到边缘侧，下面分别是简化图和详细交互模块交互图：

边缘侧

Edged

Edged可以看做是一个简化版的kubelet，负责pod生命周期的管理，并实现了和CRI，Volume，ConfigMap，Secret等功能的对接。

这里看一个pod在Edged添加的时序图，其他的流程类似：

EdgeHub

和CloudHub打交道，支持的协议有websocket和QUIC（QUIC由于其在握手方面做了大量优化，以及在断线重连上的优势，非常适合用于边云之间的通信），EdgeHub的主要功能有：

• Keep Alive
• Publish Client Info
• Route to Cloud
• Route to Edge

下图展示了Route To Cloud的流程，主要有以下几个步骤：

1. 通过Beehive框架提供的功能，持续的从EventBus、MetaManager、DeviceTwin中接收消息
2. 将消息发送给CloudHub

下图展示了Route To Edge的流程，主要有以下几个步骤：

1. 从CloudHub中接收消息
2. 将消息发送给EventBus、MetaManager、DeviceTwin

EventBus

EventBus负责在mqtt topic中间进行收发消息。

目前EventBus订阅了以下topic：

• $hw/events/upload/#
• SYS/dis/upload_records
• SYS/dis/upload_records/+
• $hw/event/node/+/membership/get
• $hw/event/node/+/membership/get/+
• $hw/events/device/+/state/update
• $hw/events/device/+/state/update/+
• $hw/event/device/+/twin/+

EventBusFlow

1、eventbus sends messages from external client.（device app通过mqtt broker将信息发布给EventBus）

2、eventbus sends response messages to external client.（EventBus通过mqtt broker将信息发给device app）

Meta Manager

MetaManager是一个在Edged和EdgeHub之间传递信息的模块，它负责从SQLite中存取设备元数据。

DeviceTwin

DeviceTwin是IoT中的一个重要的概念，设备通常包含两类数据：

• 一是不会改变的元数据，包括序列号、资产标识符、Mac地址等描述设备的详细信息，也可以称为设备的静态属性或设备属性。
• 另一类是设备的动态数据，包括特定背景下的设备专有实时数据，例如灯的开、关状态，也可以称为设备的孪生属性。

设备孪生具有与物理设备相同的特性，便于设备与应用之间进行更好地通信。应用发送的命令首先到达设备孪生，设备孪生根据应用设置的Expected State（期望的状态）进行状态更新，此外设备实时反馈自身的Actual State（真实的状态），设备孪生同时记录设备的Actual State和Expected State。这种方式也使设备在离线状况下再次上线时，设备的状态也能得到同步。

DeviceTwin有如下功能：

• Membership Module：管理edge node和edge devices之间的关系。
• Twin Module：设备孪生管理，将设备状态同步给Cloud，并保证Expected State的达成，等。
• Communication Module：和EdgeHub、EventBus通信。
• Device Module：设备静态状态管理。

DB设计：DB采用SQLite

• 设备表

• 设备状态表

• 设备孪生表

DeviceTwin示例

这个名为“light”的设备定义一个名为“powerstatus”的孪生属性，期望值（expected）是ON，而实际值（actual）是OFF。

{
    "device": {
        "id": "989e4fc8-9f24-44d7-9f9c-a0bd3bfb1949",
        "description": "my home light",
        "name": "light",
        "state": "online",
        "twin": {
            "powerstatus": {
                "expected": {
                    "value": "ON"
                },
                "actual": {
                    "value": "OFF"
                },
                "metadata": {
                    "type": "string"
                }
            }
        }
    }
}

Mapper

为了避免edgecore引入量处理边缘设备通信的代码，同时保持整个项目良好的易定制性，KubeEdge设计了一个边缘设备驱动统一管理引擎Mapper。

Mapper之于KubeEdge的作用如同CRI之于Kubernetes，只是CRI作为Kubernetes定义的容器接口与底层容器引擎打交道，而Mapper作为一个开放接口方便不同的设备协议接入KubeEdge这个边缘计算平台。

目前KubeEdge官方支持Bluetooth和ModBus两种Mapper。

其他组件

• EdgeMesh：基于Istio的横跨Cloud和Edge的服务网格解决方案。
• EdgeSite：为满足在边缘需要完整集群功能的场景，定制的在边缘搭建既能管理、编排又能运行负载的完整集群解决方案。

实验环境及实验截屏（web-app-demo）

本实验均来自kubeedge社区的example工程，地址：github.com/kubeedge/examples

实验目标

1、在k8s cluster上安装KubeEdge，并加入一个边缘节点。

2、在k8s集群上运行一个web-app，主要功能是下发音乐播放的指令到边缘节点，边缘节点负责运行pi-app，具备音乐播放功能，并播放云端下发的音乐。

组网图

节点信息

资源信息

云端节点 & web-app & pi-app

节点：lab1(cloud)

从下图可以看到边缘节点master，模拟设备speaker-01，以及kubeedge-web-app云上应用

节点：master (edge)

下图可以看到pi-player-app运行在边缘节点上，这里在Linux上运行这个应用，如果有raspberrypi的话，还可以放到raspberrypi上运行。

运行截图

1、进入web-app控制页面

2、点击播放

1）kubectl logs -f kubeedge-web-app-5749c78b98-6lbb6，查看web-app收到的日志，可以看到收到了控制信息，并且成功的调用了k8s API server的patch指令，更新了device状态。

2）pi-player-app订阅mqtt broker的信息，收到信息并调用播放功能（这里由于omxplayer需要在raspberrypi中运行，因此这里报错）

可以看到，整个边云的通讯流程已经打通，并且能够运行简单的设备指令。

kubeedge各组件交互流程

cloud-app(kubeedge-web-app) <--> k8s API <--> controller <--> cloudcore <--> edgecore <--> mqtt broker(mosquito) <--> edge-app(pi_player-app)

KubeEdge消息格式

KubeEdge消息采用json格式，整个格式分为3部分：header、route、content。

• header：msg_id、parent_msg_id、timestamp、resourceversion、sync；
• route：source、group、operation、resource；
• content：各组件自行定义。

更多的信息请参考kubeedge官方文档