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