有关Kubeedge的前言

kubeedge是华为在KubeCon CloudNativeCon China 2018上发布的面向边缘环境容器管理平台。kubeedge能够接入云端Kubernetes集群，使得边缘端应用的管理可以跟云端应用的管理一样，采用广为熟知的Kubernetes API。。KubeEdge 还支持 MQTT 协议，允许开发人员编写客户逻辑，并在边缘端启用设备通信的资源约束。

优势

kubernetes + 容器的组合大大提高了用户创建部署应用的效率。kubernetes 可以把 n 台主机整合成一个集群，用户在 master 节点上通过编写一个 yaml 或者 json 格式的配置文件，也可以通过命令等请求 Kubernetes API 创建应用，就直接将应用部署到集群上的各个节点上，该配置文件中还包含了用户想要应用程序保持的状态，从而生成用户想要的环境。
Kubernetes 作为容器编排的标准，自然会想把它应用到边缘计算上，即通过 kubernetes 在边缘侧部署应用，但是 kubernetes 在边缘侧部署应用时遇到了一些问题，例如：

• 边缘侧设备没有足够的资源运行一个完整的 Kubelet
• 一些边缘侧设备是 ARM 架构的，然而大部分的 Kubernetes 发行版并不支持 ARM 架构
• 边缘侧网络很不稳定，甚至可能完全不通，而 kubernetes 需要实时通信，无法做到离线自治
• 很多边缘设备都不支持TCP/IP 协议
• Kubernetes 客户端（集群中的各个Node节点）是通过 list-watch 去监听 Master 节点的 apiserver 中资源的增删改查，list-watch 中的 watch 是调用资源的 watch API 监听资源变更事件，基于 HTTP 长连接实现，而维护一个 TCP 长连接开销较大。从而造成可扩展性受限。

image.png

为了解决包含但不限于以上 Kubernetes 在物联网边缘场景下的问题，从而产生了KubeEdge 。对应以上问题：

• KubeEdge 保留了 Kubernetes 的管理面，重新开发了节点 agent，大幅度优化让边缘组件资源占用更低很多
• KubeEdge 可以完美支持 ARM 架构和 x86 架构
• KubeEdge 有离线自治功能，可以看 MetaManager 组件的介绍
• KubeEdge 丰富了应用和协议支持，目前已经支持和计划支持的有：MQTT、BlueTooth、OPC UA、Modbus等。
• KubeEdge 通过底层优化的多路复用消息通道优化了云边的通信的性能，可以看 EdgeHub 组件的介绍

image.png

介绍

应用场景、特点等

image.png

image.png

上图是 华为云IEF 的应用场景，Kubeedge 就是源于这个产品，它基于 KubeEdge 和 Kubernetes 生态构建，将云原生的技术应用到边缘计算。IEF 通过纳管边缘节点，将云端AI应用、函数计算等能力下发到边缘节点（EdgeNode），将公有云能力延伸到靠近设备的一端，使得边缘节点拥有云端相同能力，能够实时处理终端设备计算需求。

架构

image.png

整体架构图比较明了，在不考虑edgesite的情况下，其架构分为了云端和边缘端。其实可以理解为kubernetes的管理侧和kubelet节点侧（对应edge端）。但是请注意，这里的场景是边缘计算，意味着edge端的网络环境难以保障。

云边通信

于是就衍生出了cloud端的cloud Hub与edge端的Edge Hub。这两个模块之间通过websocket或者quic通信，相当于建立了一条底层通信隧道，供k8s和其他应用通信。当然，使用什么协议通信不是重点，重点是如何保障当着之间的链路都无法保障的时候，业务不受到影响，这就是MetaManager的要解决的问题了。

• CloudHub
  前面提到cloud端的cloudHub就是一个隧道的server端，用于大量的edge端基于websocket或者quic协议连接上来；
• EdgeHub
  位于edge端运行，是隧道的client端，负责将接收到的信息转发到各edge端的模块处理；同时将来自个edge端模块的消息通过隧道发送到cloud端。

边缘端

• MetaManager
  MetaManager模块后端对应一个本地的数据库（sqlLite），所有其他模块需要与cloud端通信的内容都会被保存到本地DB一份，当需要查询数据时，如果本地DB中存在该数据，就会从本地获取，这样就避免了与cloud端之间频繁的网络交互；同时，在网络中断的情况下，本地的缓存的数据也能够保障其稳定运行（比如你的智能汽车进入到没有无线信号的隧道中），在通信恢复之后，重新同步数据。
• Edged
  之前提到过kubernetes的kubelet，它相当于k8s的核心。这块其实简单做了一些裁剪，去掉一些用不上的功能，然后就成为Edged模块，该模块就是保障cloud端下发的pod以及其对应的各种配置、存储（后续会支持函数式计算）能够在edge端稳定运行，并在异常之后提供自动检测、故障恢复等能力。当然，由于k8s本身运行时的发展，该模块对应支持各种CRI应该也比较容易。
• EventBus/ServiceBus/Mapper
  前面讲到的模块都与k8s直接或间接相关，接下来说下与设备（或者说真正IOT业务）相关的设备管理侧。外部设备的接入当前支持MQTT和Rest-API，这里分别对应EventBus和ServiceBus。EventBus就是一个MQTT broker的客户端，主要功能是将edge端各模块通信的message与设备mapper上报到MQTT的event做转换的组件；而ServiceBus就是对应当外部是Rest-API接入时的转换组件。说道这里，就有必要提一下MQTT broker，互联网的开发者的基本都用过类似于rabbitmq、activeMQ之类的消息中间件，他们就支持MQTT协议（可以理解为AMQP的精简版）。IOT的各种设备可能直接支持MQTT，但有的只支持蓝牙或者其他近场通信的协议。没关系，Mappper可以实现将各种协议转换为对MQTT的订阅与发布，从而实现与edge端的通信。当然，ServiceBus对应就适用于支持http协议的服务。
• DeviceTwin
  edge端最后就剩下一个DeviceTwin模块了，要理解这个名词，就得提一下数字孪生这个概念。DeviceWin 就是保证设备状态在云端和边缘端同时存在。DeviceTwin就是将这些信息保存到本地DB中，并处理基于cloud端的操作来修改device的某些属性（也就是操作设备）；同时，将设备基于eventBus上报的状态信息同步到本地DB和cloud端的中间人。

云端

• Controller
  然后再说controller，其实准确的说controller是包括了用于edge端与API-Server同步信息的edgeController与用于DeviceTwin与API-Server同步device CRD信息的deviceController组成。这两个模块相对也比较简单，后面具体讲解。

除了官方架构图展示的Cloud和Edge部分外，还有横跨Cloud和Edge的部分，具体如下：

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

系统要求

256M内存、能够运行docker容器。比如树莓派 Raspberry PI。

用户
通常用户最关心的是， 在这个架构下，要实现一个功能，最少需要做些什么。我们就以温度收集器为例。

安装

这是一次性的工作，可以参考网上的帖子： https://www.cnblogs.com/kkbill/p/12600541.html

Sample yaml:

build/coloud
build/edge

应用

虽然kebeedge很复杂，但是对于用户的应用，通常只要实现Mapper 和 设备的Spec， 然后就可以使用了。

• Mapper
  请看代码https://github.com/kubeedge/examples/tree/master/temperature-demo/temperature-mapper

收集传感器的温度，经过协议转换发向边缘端。

• Device Spec
  https://github.com/kubeedge/examples/tree/master/temperature-demo/crds

• Steps
  https://github.com/kubeedge/examples/tree/master/temperature-demo