Kubeedge概述

1. kubeedge是什么

KubeEdge基于Kubernetes构建，并将容器化的应用编排和设备管理扩展到端上的主机。 它由云端和边缘端组成，为网络，应用的部署以及云和边缘之间的元数据同步提供架构支持。 它还支持MQTT，它使边缘设备可以通过边缘节点进行访问。

借助KubeEdge，可以轻松地将现有的复杂机器学习，图像识别，事件处理和其他高级应用程序部署和部署到Edge。 借助在Edge上运行的业务逻辑，可以在生成数据的本地保护和处理大量数据。 通过在Edge处理数据，可以大大提高响应速度，并保护数据隐私。

2. 特点

• kubernetes 原生支持，cloud-core部分的code 使用 client-go，监控了k8s 资源的变化，对原有的k8s 集群没有任何影响。

• 云-边的可信任通信，使用websocket 通信，并通过ACK等机制保证消息方式保证消息可靠传递

• 边侧的自治，当edge节点掉线的时候，保证运行在edge的应用不会有影响，

• edge侧的设备管理，目前支持MQTT

• 轻量级，edge-core 的运行负载低，树莓派等跑起来毫无压力

  ---

• edge端目前还是依赖docker，装的还是太重了。

• cloud-core部分，还是进程启动，无高可用可言，也不是deployment部署的，今年的roadmap计划解决。

• 安装部署，keadm的使用出错率特别高，还需要执行ca证书的拷贝，使用很不方便，自动化部署需要加强。

• 日志全打一个，很不好安装模块区分，排错，日志查看不便，也没有日志的滚动。

• 无法在edge端实现类似ingress 的访问。

以上当然还是有大量pr的提交机会。

3. 如何工作的

云部分

• CloudHub：Websocket server，负责在云侧观察更改，缓存并向EdgeHub发送消息。

• EdgeController：一个kubernetes controller，它管理边缘节点和云侧的数据，以便可以将数据定向到特定的边缘节点。

• DeviceController：一个kubernetes controller，用于管理设备，以便可以在边缘和云之间同步设备元数据/状态数据。

• SyncController：一个kubernetes controller，用于将objectsyncs指定的资源触发一次同步。是1.2.1 里新增的conrtoller。

  目前kubeedge 提供了4种CRD：

  • clusterobjectsyncs (集群级别的对象同步)
  • objectsyncs namespace 级别的对象同步
  • devices （设备）
  • devicemodels（设备模板）

  对应了2个controller：

  • synccontroller，
  • DeviceController

边缘部分

• EdgeHub：Websocket 客户端，负责与Cloud Service进行交互，包括将云侧资源更新同步到边缘，并将边缘侧主机和设备状态更改报告给云。
• Edged：在边缘节点上运行并管理容器化应用的Agent，类似kubelet，增强了cm，secret，等资源的cache。
• EventBus：与MQTT服务器（mosquitto）进行交互的客户端，提供对其他组件的发布和订阅功能。
• ServiceBus：与HTTP服务器（REST）交互的HTTP客户端，为云组件提供HTTP客户端功能，以访问在边缘运行的HTTP服务器，提供的是服务暴露的功能。
• DeviceTwin：负责存储设备状态并将设备状态同步到云。它还为应用程序提供查询接口。
• MetaManager：edged和edgehub之间的消息处理器。它还负责将元数据存储到轻量级数据库（SQLite）或从中检索元数据。

4.部署

• tke 部署k8s

• kubectl delete -f https://raw.githubusercontent.com/coreos/flannel/2140ac876ef134e0ed5af15c65e414cf26827915/Documentation/kube-flannel.yml
  

  删了tke自带的flannel网络，重新部署flannel。

  kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/2140ac876ef134e0ed5af15c65e414cf26827915/Documentation/kube-flannel.yml
  

• 下载kubeedge到指定目录，修改当前主机hosts文件。

  151.101.72.133 raw.githubusercontent.com
  

• 从源码编译keadm

  git clone https://github.com/kubeedge/kubeedge.git $GOPATH/src/github.com/kubeedge/kubeedge
  cd $GOPATH/src/github.com/kubeedge/kubeedge
  make all WHAT=keadm
  

  在云端执行：

  ./keadm init
  

  把产生的ca证书文件和certs 服务证书文件，手工拷贝到端侧，并执行：

  ./keadm join --cloudcore-ipport=10.206.0.9:10000 --edgenode-name=edge --kubeedge-version=1.2.1
  

5. code 的解读

• 基础：

• client-go: listwatcher, informer，informer-factory，indexer

  • Informer A general structure of an Informer is described below:

  store, controller := cache.NewInformer {
  	&cache.ListWatch{},
  	&v1.Pod{},
  	resyncPeriod,
  	cache.ResourceEventHandlerFuncs{},
  

  • ListWatcher The client-go library provides the Listwatcher interface that performs an initial list and starts a watch on a particular resource:

    lw := cache.NewListWatchFromClient(
          client,
          &v1.Pod{},
          api.NamespaceAll,
          fieldSelector)
    

• controller :
  The simplest implementation of a controller is a loop:

  for {
    desired := getDesiredState()
    current := getCurrentState()
    makeChanges(desired, current)
  }
  

  • workqueue

    算法非常小巧，引入一个dirty 的set，用于快速判断是否已经在处理队列中； 引入一个processing 的set 用于保存正在处理的item：
    

  • Worker

    workqueue的消费者，示例： edgecontroller 的downcontroller。

  • EventHandler

    type ResourceEventHandlerFuncs struct {
    	AddFunc    func(obj interface{})
    	UpdateFunc func(oldObj, newObj interface{})
    	DeleteFunc func(obj interface{})
    }
    

  整体逻辑：

• beehive

  基于golang channel机制实现的消息总线，主要是用于进程内部的模块之间的通讯解耦。

  执行test，直观体验。

6. code 部分的解读

• Kubeedge TODO，未来要写很多。

7. Examples