https://release-1-19.docs.kubeedge.io

KubeEdge 架构

云上组件（Cloud Core）：

  • CloudHub

  • EdgeController

  • DeviceController

边缘组件（Edge Core）：

  • Edged

  • EventBus

  • EdgeHub

  • DeviceTwin

  • MetaManager

  • ServiceBus

1、Cloud Core

1.1、CloudHub

CloudHub 是 cloudcore 的一个模块，是 Controller 和 Edge 端之间的中介。它同时支持基于 web-socket 的连接以及 QUIC 协议访问。 edgehub 可以选择其中一种协议来访问 cloudhub。CloudHub 的功能是启用 Edge 和 Controller 之间的通信。

1.2、EdgeController

Edge Controller 是Kubernetes Api-Server和 EdgeCore 之间的桥梁。

Edge Controller执行以下功能：

  • 下行控制器(Downstream Controller)：从K8s Api-server同步添加/更新/删除事件到EdgeCore

  • 上行控制器(Upstream Controller)：同步监视并更新资源和事件的状态（节点、Pod 和 ConfigMap）到 K8s Api-server，并且订阅来自 EdgeCore 的消息

  • Device Manager：创建管理接口，实现管理ConfigmapManager,LocationCache 和 PodManager 的事件

（1）Downstream controller

同步添加/更新/删除事件到边缘​

  • Downstream Controller：监视K8S Api-server并通过cloudHub发送更新到EdgeCore

  • 通过cloudHub同步Pod, ConfigMap, Secret 的添加/更新/删除事件到边缘

  • 通过调用Upstream Controller管理接口创建相应的管理器（Pod,ConfigMap,Secret）来处理事件

  • 定位ConfigMap和Secret应发送到哪个节点

Downstream Controller

（2）Upstream controller

同步监视并更新资源和事件的状态​

  • Upstream Controller接收来自EdgeCore的消息，并将更新同步到K8S Api-server

  • 创建停止通道以分发和停止处理Pod,ConfigMap节点和Secret事件

  • 创建消息通道以更新NodeStatus,PodStatus,Secret和ConfigMap相关事件

  • 获取Pod状态信息，如Ready,Initialized,PodScheduled和Unschedulable详细信息

  • 以下是 PodCondition 的信息
       - Ready：PodReady表示Pod能够提供服务请求，并应添加到所有匹配服务的负载均衡池中
       - PodScheduled：它表示此Pod的调度过程状态
       - Unschedulable：表示调度器当前无法调度此Pod，可能是由于集群中的资源不足
       - Initialized：表示Pod中的所有初始化容器均已成功启动
       - ContainersReady：表示Pod中的所有容器是否都已准备好

  • 以下是 PodStatus 的信息
       - PodPhase：Pod的当前状态
       - Conditions：指示Pod处于此状态的详细信息
       - HostIP：分配给Pod的主机的IP地址
       - PodIp：分配给Pod的IP地址
       - QosClass：根据资源需求分配给Pod的QoS类别

Upstream Controller

1.3、DeviceController

Device Controller是KubeEdge的云端组件，负责设备管理。在KubeEdge中，设备管理是通过使用CRD机制来描述设备的元数据和状态，并通过Device Controller在Edge node和Cloud之间同步这些设备更新来实现的。

DeviceController启动了两个独立的协程，分别成为上行控制器和下行控制器。他们并不是单独的控制器，只是为了便于理解而命名。

Device Controller利用设备模型(Device Model)和设备实例(Device Instance)来实现设备管理：

  • Device Model：Device Model描述了设备公开的设备属性以及访问这些属性的属性访问者。Device Model类似于可重复使用的模板，用于创建和管理不同类型的设备。Device Model定义的详细信息可以在这里找到。

  • Device Instance：Device Instance代表一个实际的设备对象。它类似于Device Model的实例化，并引用模型中定义的属性。Device Instance中device.spec是静态的，而device.status包含动态变化的内容，如设备属性的期望状态和设备报告的实际状态。设备实例定义的详细信息可以在这里找到。

Device Model

Device Controller执行以下功能：

  • Downstream Controller：通过监视 K8S API Server，将设备更新从云端同步到边缘节点。

  • Upstream Controller：使用Device Twin组件，将设备更新从Edge node同步到云端。

设备模型（Device Model）描述了一类设备公开的设备属性。设备模型是一种“物理模型”，它约束物理设备的属性和参数。

apiVersion: devices.kubeedge.io/v1beta1
kind: DeviceModel
metadata:
  name: beta1-model
spec:
  properties:
    - name: temp
      description: beta1-model
      type: INT
      accessMode: ReadWrite
      maximum: "100"
      minimum: "1"
      unit: "Celsius"
  protocol: modbus

在上面的例子中，定义了一个名为 beta1-model 的设备模型，该模型使用 modbus 协议，定义了一个名为temp的设备属性，其数据类型为int。 此外，还定义了设备属性的访问方式、取值范围和单位。

设备实例（Device Instance）代表一个实际的设备对象。

设备实例的spec字段是静态的，包括设备属性列表，它描述了每个属性的详细信息，包括其名称、类型、访问方法。

apiVersion: devices.kubeedge.io/v1beta1
kind: Device
metadata:
  name: beta1-device
spec:
  deviceModelRef:
    name: beta1-model
  nodeName: worker-node1
  properties:
    - name: temp
      collectCycle: 10000000000  # The frequency of reporting data to the cloud, once every 10 seconds
      reportCycle: 10000000000   # The frequency of data push to user applications or databases, once every 10 seconds
      reportToCloud: true
      desired:
        value: "30"
      pushMethod:
        mqtt:
          address: tcp://127.0.0.1:1883
          topic: temp
          qos: 0
          retained: false
        dbMethod:
          influxdb2:
            influxdb2ClientConfig:
              url: http://127.0.0.1:8086
              org: test-org
              bucket: test-bucket
            influxdb2DataConfig:
              measurement: stat
              tag:
                unit: temperature
              fieldKey: beta1test
      visitors:
        protocolName: modbus
        configData:
          register: "HoldingRegister"
          offset: 2
          limit: 1
          scale: 1
          isSwap: true
          isRegisterSwap: true
  protocol:
    protocolName: modbus
    configData:
      ip: 172.17.0.3
      port: 1502

上面的例子中，定义了一个名为 beta1-device 的设备，与之关联的设备模型为beta1-model，设备运行的节点为worker-node1。

示例文件在spec.properties字段中定义设备属性，包括消息上报频率、消息推送方式（spec.properties.pushMethod）、以及访问设备所需的参数（spec.properties.visitors）。此外，设备使用的协议在spec.protocol字段中定义。

2、Edge Core

2.1、Edged

EdgeD 是一个管理 Pod 生命周期的边缘节点模块。它可以帮助用户在边缘节点部署容器化工作负载或应用程序。使用云端的 kubectl 命令行界面，用户可以发出命令来启动工作负载。通过容器运行时接口 （CRI） 支持多个符合 OCI 标准的运行时。

2.2、EventBus

Eventbus 充当在 mqtt 主题上发送/接收消息的接口。

2.3、EdgeHub

Edge Hub 负责与云中存在的 CloudHub 组件进行交互。它可以使用 Web 套接字连接或使用 QUIC 协议连接到 CloudHub。支持同步云端资源更新、边侧主机上报、设备状态变化等功能。

它充当边缘和云之间的通信链路。它将从云端接收到的消息转发到边缘的相应模块，反之亦然。

EdgeHub 执行的主要功能是：

  • Keep Alive

  • Publish Client Info

  • Route to Cloud

  • Route to Edge

2.4、DeviceTwin

DeviceTwin 模块负责存储设备状态，处理设备属性和设备孪生操作，在边缘设备与边缘节点之间创建关联，将设备状态同步到云端，并在边缘和云端之间同步设备孪生信息。它还为应用程序提供查询接口。DeviceTwin 由四个子模块（即 Membership 模块、Communication 模块、Device 模块和 Twin 模块）组成，以履行 DeviceTwin 模块的职责。

以下是 DeviceTwin Controller 的功能：

  • 将元数据同步到数据库/从数据库同步元数据 （ Sqlite ）

  • 注册和启动子模块

  • 将消息分发到子模块

  • 健康检查

2.5、MetaManager

MetaManager 是 edged 和 edgehub 之间的消息处理器。它还负责在轻量级数据库（SQLite）中存储/检索元数据。

Metamanager 有下列操作：

  • 插入

  • 更新

  • 删除

  • 查询

  • 响应

  • 节点连接

  • 元数据同步

创建新对象时，将通过云接收 插入 操作消息。例如，通过云创建/部署的新用户应用程序 Pod。

Insert Operation

edgehub 通过云接收 插入 操作请求。它将请求分派给 MetaManager，其将此消息保存在本地数据库中。然后，MetaManager 向 edged 发送异步消息。edged 处理插入请求，例如通过启动 pod 并在消息中填充响应。MetaManager 检查消息，提取响应并将其发送回 Edged，Edge 将其发送回云端。

更新 操作可以发生在云/边缘的对象上。

更新消息流类似于插入操作。此外，metamanager 会检查正在更新的资源是否已在本地更改。只有存在差异的时候，更新的数据才会被存储到本地，并且更新消息被传递给 edged ，响应被返回给云端。

Update Operation

当云端有对象（例如 Pod）被删除时，删除操作会被触发

Delete Operation

查询操作 使您可以在边缘本地查询元数据，也可以从云中查询一些远程资源（如 maps/secrets）。Edged 从 metamanager 查询此元数据，metamanager 进一步处理本地/远程查询处理，并将响应返回给 edged。Message 资源可以根据分隔符 '/' 分为 3 个部分 （resKey、resType、resId）。

Query Operation

2.6、ServiceBus

ServiceBus 是一个 HTTP 客户端，用于与 HTTP 服务器 （REST） 交互，为云组件提供 HTTP 客户端功能，以访问在边缘运行的 HTTP 服务器。

该设计与 EventBus 的设计相似。

EventBus 用于通过 MQTT 与在边缘上运行的应用程序进行通信。同样，ServiceBus 用于通过 HTTP 与在边缘上运行的应用程序进行通信。

  • Cloud 通过 CloudHub 向 Edge 发送 beehive 消息。

  • EdgeHub 接收消息并将其发送到 ServiceBus。

  • ServiceBus 仅进行 HTTP 调用，并通过 EdgeHub 将响应发送到云。

ServiceBus flowchart

3、Mapper

Mapper是KubeEdge和设备之间的管理器。它可以设置/获取设备数据，获取并报告设备状态。KubeEdge使用Device Controller、Device Twin和Mapper来控制设备。Device Controller位于云端，它使用CRD来定义和控制设备。 Device Twin位于边缘侧，它能够存储来自Mapper的值/状态并在Mapper与Device Controller之间传递消息。同时，Device Twin中的DMI用于向云端注册Mapper并把Device Model与Device Instance传递给Mapper。

mapper