KubeEdge：下一代云原生邊緣設備管理標準DMI的設計與實作

摘要：KubeEdge設備管理架構的設計實作，有效幫助用戶處理設備數字孿生行程中遇到的場景，

本文分享自華為云社區《KubeEdge：下一代云原生邊緣設備管理標準DMI的設計與實作》，

隨著5G、AI、分布式云等技術的成熟發展，萬物互聯、數字孿生、算力泛在等理念不斷推進，帶來了很多行業業務的創新，越來越多的設備、應用運行在端側，并產生大量的資料，如何更好地解耦業務應用開發和設備資料訪問，為設備提供完整的生命周期資料管理，釋放設備資料的價值？如何在保證集群可用性的同時，高效管理和傳輸設備資料，獲得更為方便、靈活的資料訪問方式？云原生邊緣計算的方案選擇可以幫助用戶更好地應對這類問題，

一、KubeEdge設備管理框架

KubeEdge設備管理架構的設計實作，有效幫助用戶處理設備數字孿生行程中遇到的場景，用戶可以通過KubeEdge，將物理設備抽象成數字孿生，用云原生的方式對設備和資料進行管理，

KubeEdge設備管理架構設計如圖1所示，具體流程如下：

1. 用戶呼叫Kubernetes API介面，創建Device CRD實體到KubeEdge
2. KubeEdge云上組件CloudCore watch到Kubernetes中Device CRD實體創建訊息
3. 此時CloudCore會做兩件事情，一方面CloudCore通過云邊websocket通道下發Device Twin資訊到EdgeCore，另一方面CloudCore會生成一份包含Device Profile資訊的Configmap，該Configmap是以Node名稱為索引，掛載到對應Mapper的Pod中的
4. Mapper通過讀取掛載的Configmap中的Device Profile資訊，更新本地維護的Device list串列
5. EdgeCore把接收到的Device Twin資訊發送到指定的mqtt topic
6. 該節點上的所有Mapper都會收到該Device Twin訊息，并根據Device名稱來匹配是否是自己維護的list中的Device
7. Mapper根據Device Profile資訊，通過對應的協議與設備建立連接
8. Mapper通過mqtt topic上報設備狀態和采集的資料Device Twin到EdgeCore
9. EdgeCore通過云邊websocket通道上報Device Twin資料到CloudCore
10. CloudCore更新設備Device Twin資料到Kubernetes

二、DMI框架設計

在此基礎上，KubeEdge團隊也對框架不斷更新迭代，為幫助用戶應對未來更大規模設備場景、更高的可用性需求、更靈活的功能支持以及更優的用戶體驗，KubeEdge 設計了更優化的設備管理框架——DMI，

DMI整合設備管理介面，優化邊緣計算場景下的設備管理能力，打造基于云原生技術的，覆寫設備管理、設備資料的設備數字孿生管理平臺；同時定義了EdgeCore與Mapper之間統一的連接入口，并分別由EdgeCore和Mapper實作上行資料流和下行資料流的服務端和客戶端，承載DMI具體功能，

DMI框架設計中解耦了設備管理面與設備業務面資料，讓Device CRD只承載設備本身的生命周期管理，而設備業務面資料則直接通過微服務的方式為資料消費者應用提供出來，在這樣的架構下，設備就不再是單純的資料源，而是一種云原生的設備微服務，設備資料消費應用的開發者就可以不再關心如何獲取設備資料，而是以更云原生的方式來聚焦應用本身的業務邏輯開發，DMI框架還提供多種資料推送方式，讓資料消費者可以更靈活地獲取設備資料，用戶體驗更優，

由于DMI的設備管理面與業務面資料分離的特點，業務面資料可以通過業務面通道更靈活地在云端或邊端被處理，而管理面的云邊通道中只會傳輸少量管理面資訊，大大降低了云邊通道擁塞的可能，提高了KubeEdge系統的可用性，另外，DMI提供了統一的設備管理相關介面，無論是設備應用開發者還是設備應用的使用者，都可以以更統一、更靈活、更標準化的方式來開展設備相關作業，不拘泥于具體形式，只要能夠實作DMI介面，就能夠享受KubeEdge邊緣計算平臺帶來的云原生設備管理體驗，

▍2.1 DMI框架定位

DMI在KubeEdge架構中的定位如圖2所示，DMI類似Kubernetes的CNI、CSI、CRI等介面，定義了一組EdgeCore與Mapper之間的內部API介面以及外部應用訪問Mapper的統一的API介面，其中內部介面底層由gRPC結合UDS的方式來實作，外部API介面支持mqtt和REST兩種接入方式，Mapper不論是何種承載、實作方式，只要實作了DMI中所定義的上行、下行資料介面，即可接入KubeEdge云原生邊緣計算平臺，使用云原生的方式對設備進行管理，

▍2.2 DMI設備管理與資料管理

DMI框架架構設計如圖3所示，其中黃色線條為設備管理面資料流管理，藍色部分為業務面資料流管理，

在DMI的架構設計中，將設備的管理面資料與業務面資料進行分離，其中管理面資料主要包括設備的元資料、設備屬性、配置、狀態、生命周期等，其特點是相對比較穩定，創建后除狀態上報外的資訊更新較少，更貼近Pod型別資源所產生的資料，在保證用戶可以通過云端Kubernetes API像訪問Pod一樣維護Device的生命周期的同時，盡量減少設備管理產生的額外資料傳輸開銷，

在DMI框架設計下，設備不再是單純的資料源，而是被抽象為微服務，以云原生的方式為設備資料消費者提供資料服務，DMI框架下的設備資料訪問支持多種場景，更加靈活，圖3中列出了幾種主要的資料訪問方式，包括推資料和拉資料等，具體情況如下：

1. 邊緣側應用通過REST Service訪問設備資料
2. 云側應用通過REST Service訪問設備資料
3. Mapper通過配置REST目的地址，將資料推送到邊緣側應用
4. Mapper通過配置REST目的地址，將資料推送到云側應用
5. Mapper通過配置目的地址，將資料推送到邊緣側資料庫
6. Mapper通過配置目的地址，將資料推送到mqtt broker
7. 邊緣側應用通過mqtt broker topic訂閱設備資料
8. 云側應用通過mqtt broker topic 訂閱設備資料
9. 邊緣側應用處理資料后將處理結果傳上云

▍2.3 DMI作業流程

在DMI框架下，設備管理作業的流程有一定的變化，如圖4所示，在安裝KubeEdge的時候，云端CloudCore會注冊DeviceController組件用于監聽Device和DeviceModel的CRD資源，DeviceController中存在兩個模塊，Downstream Controller和Upstream Controller，其中Downstream Controller用于監聽云端的Device、DeviceModel事件，并通過Cloudhub下發至邊緣，Upstream Controller用于接收從Cloudhub轉發來的EdgeHub上報的Device狀態和訊息，并更新Kubernetes中的Device狀態，在邊緣側，Mapper初始化的時候，需要呼叫DMI中的Mapper注冊介面，將Mapper的相關資訊注冊至Device Manager，并接收介面回傳的已下發至該節點的且協議匹配的設備資訊，EdgeHub在接收到云端下發的設備訊息時，會將其轉發到DeviceManager組件，DeviceManager會根據該設備的協議選擇對應的Mapper驅動程式，發送創建設備的請求，并且本地資料庫也會存盤該設備的資訊，后續Mapper會將設備孿生訊息轉化為設備協議格式，跟實際的物理設備進行通信，

三、DMI介面定義

▍3.1 DMI 介面分類

DMI介面實作了EdgeCore與Mapper之間的通信，支持REST和mqtt的通信方式，并以標準化的形式呈現，降低了Mapper開發、適配難度，在資料訪問方面，DMI可以實作邊緣側和云側的應用都可以通過REST Service的方式訪問設備資料，

如圖5所示，DMI有六類介面，Mapper管理是針對邊緣側各類設備協議驅動程式，Device管理和Device資料管理對管理面和業務面進行了資料拆分，Device升級管理和Device命令管理為具有升級和命令執行功能的設備提供相關的介面，Device事件管理可以監控Mapper及其納管的各個設備的運行狀態，

▍3.2 DMI 介面定義示例

如圖6所示，為DMI設備管理部分介面定義，v1版本以gRPC proto的方式定義，可使用make dmi命令創建對應的gRPC-go代碼，

▍3.3 DMI 設備相關 CRD 定義

如圖7所示，是DMI設備相關CRD定義，主要分為Device和DeviceModel，其中DeviceModel與設備型號是一一對應的關系，代表同一類設備型號的共有屬性，主要包含設備產生資料屬性Properties和設備支持命令屬性Commands，Device為設備實體，與真實的物理設備為一對一的關系，每個DeviceModel可以對應統一型號的多個Device實體，Device型別資源主要包含設備型號對應關系資訊、設備協議配置資訊、設備部署節點資訊、設備狀態資訊以及設備資料Property采集配置資訊，

四、發布計劃

DMI發布計劃分為三個版本，Alpha版本提供設備管理相關功能實作，以及提供一個支持DMI介面的Mapper Demo，Beta版本支持設備命令管理、設備升級管理以及設備資料管理的能力，此外還會對接第三方平臺，并提供相關對接Demo，GA版本會對多平臺、多協議進行對接支持，另外會把設備安全以及事件管理的功能補全，

目前 KubeEdge Device IoT SIG 專注于第一階段的設備管理和 Mapper Demo 的開發作業，歡迎大家通過下方聯系方式聯系我們，一起參與到方案設計和特性開發的作業當中，

本文作者：華為云 趙然 ；DaoCloud 道客 王梓龍

附：KubeEdge社區貢獻和技術交流地址

網站: https://kubeedge.ioGithub

地址: https://github.com/kubeedge/kubeedgeSlack

地址: https://kubeedge.slack.com

郵件串列: https://groups.google.com/forum/#!forum/kubeedge

每周社區例會: https://zoom.us/j/4167237304

Twitter: https://twitter.com/KubeEdge

檔案地址: https://docs.kubeedge.io/en/latest/

點擊關注，第一時間了解華為云新鮮技術~

標籤：其他

上一篇：「游戲引擎 淺入淺出」4.2 頂點著色器

下一篇：如何給注冊中心錦上添花？