站長資訊網日前,由中國信息通信研究院主辦的云計算開源產業峰會在京召開。由華為云開源的智能邊緣項目KubeEdge在會上榮獲尖峰開源技術創新獎,華為云智能邊緣云首席架構師張琦出席領獎并發表了《KubeEdge:云原生的邊緣計算平臺》的主題演講。
早在今年3月,CNCF基金會及技術委員會全體一致同意開源智能邊緣項目KubeEdge加入CNCF社區,成為CNCF在智能邊緣領域的首個正式項目。KubeEdge旨在推進云原生技術在智能邊緣領域的生態建設與普及,與全球廣大云原生社區伙伴一起共同推動智能邊緣及云原生產業的發展。
云原生與邊緣計算的完美結合
經過我們調研發現,傳統的嵌入式設備開發面臨著諸多挑戰,嚴重制約著邊緣設備上云以及大規模設備在云化場景下開發效率。
(1) 邊云生態的割裂,物理設備訪問難度高,與IT技術割裂,開發難度高產品上市周期長
(2) 日趨復雜的邊緣業務的部署,對高度分布和大規模可擴展性缺乏考慮
(3) 缺少和云的協同以及邊緣和邊緣的協同,構建分布式系統難度高
(4) OT和IT世界技術割裂,協同門檻高
那么,云原生和邊緣計算相遇,會擦出什么樣激烈的“火花”?現在大多數的邊緣設備都與云端配合使用,比如工程師們可以在云端訓練機器學習模型,訓練好之后將推理模型應用于邊緣節點。無論從邊緣應用的分發,邊緣應用的可靠性還是邊云協同的機制上,云原生邊緣計算有利于讓邊緣也具備像云一樣的“彈性”,讓應用可以“順滑”的部署到邊緣,保持應用在邊緣與云端的一致性。
KubeEdge通過更優的架構和技術實現,能完美應對當前遇到的挑戰,幫助工程師從底層技術設施的管理中解放出來,將注意力集中到更高抽象層次的應用開發之中。這樣,“云-邊-端”就像是一個完美的整體,最終用戶無需感知邊緣設備的復雜分布。
· 通過將AI能力、大數據能力等延伸到邊緣,解決與云上服務的數據協同、任務協同、管理協同、安全協同訴求
· 通過數據本地化處理、邊緣節點離線自治,解決了云和邊緣之間的網絡可靠性和帶寬限制的問題
· 通過大幅優化邊緣組件的資源占用(二進制大小約46MB,運行時內存占用約10MB),解決了邊緣資源的約束問題
· 通過在云邊之間構建的雙向多路復用網絡通道,解決了從云端管理高度分布的海量節點和設備難的問題
· 南向支持對接物聯網主流的通信協議(MQTT,Bluetooth,Zigbee,BACnet等),解決了異構硬件接入難的問題
綜合起來看,傳統的嵌入式本地計算和云原生邊緣計算的差異可以歸納如下:
KubeEdge架構
KubeEdge即Kube+Edge,顧名思義就是依托K8S的容器編排和調度能力,實現云邊協同、計算下沉、海量設備的平滑接入。KubeEdge架構上包含兩部分,分別是云端和邊緣側。云端負責應用和配置的下發,邊緣側則負責運行邊緣應用和管理接入設備。
Edged:管理邊緣的容器化應用程序。
EdgeHub:邊緣的通信接口模塊。這是一個 Web 套接字客戶端,負責邊緣計算與云服務的交互。
CloudHub:云端通訊接口模塊。一個 Web 套接字服務器,負責監視云端的更改、緩存以及向 EdgeHub 發送消息。
EdgeController:管理邊緣節點。它是一個擴展的 Kubernetes 控制器,管理邊緣節點和 pod 元數據,以便數據可以面向特定的邊緣節點。
EventBus:使用 MQTT 處理內部邊緣通信。它是一個 MQTT 客戶機,可以與 MQTT 服務器(mosquitto)交互,為其他組件提供發布和訂閱功能。
DeviceTwin:它是處理設備元數據的設備軟件鏡像。該模塊有助于處理設備狀態并將其同步到云上。它還為應用程序提供查詢接口,因為它連接到一個輕量級數據庫(SQLite)。
MetaManager:它管理邊緣節點上的元數據。這是 Edged 和 Edgehub 之間的消息處理器。它還負責在輕量級數據庫(SQLite)中存儲 / 檢索元數據。
極致優化
容器天然的輕量化和可移植性,非常適合邊緣計算的場景,鑒于K8S已經成為云原生編排的事實標準,因此攜手K8S進入邊緣將很有可能結束邊緣計算當前混沌的狀態,并定義云端和邊緣統一的應用部署和管理的標準。
然而,由于邊緣場景通信的不穩定性和嚴苛的資源消耗限制,導致原生的K8S組件無法直接運行在邊緣節點上,例如:工業網關等。而受限于K8S本身list/watch機制帶來的disconnect問題,數據面和管理面斷連后,無法做到本地自治。
KubeEdge選擇的是“輕邊緣”架構,即邊緣側的容器引擎和設備管理agent盡量輕量化,管理面運行在云端,且構建在K8S的調度能力之上,100%兼容K8S原生API。KubeEdge all in K8S的設計理念使得用戶可以圍繞K8S的標準API定制需求或者輕松集成云原生生態中的成熟項目。
從ServiceMesh到EdgeMesh
在過去的一年中,服務網格(Service Mesh)已經演變成為云原生堆棧的重要組成部分。像 Paypal,Lyft,Ticketmaster 和 CreditKarma 這樣的高流量公司都已經為其生產應用添加了 ServiceMesh。ServiceMesh與云原生應用的興起有關。在云原生模型中,單個應用程序可能包含數百個服務,每個服務可能有數千個實例,并且這些實例中的每一個都可能處于不斷變化的狀態,合理管理使用 ServiceMesh,對于確保端到端的性能和可靠性至關重要。
隨著信通院《云計算與邊緣計算協同九大應用場景(2019年)》的發布,“云邊協同是邊緣計算發展的重要驅動力和不可分割的需求”已經逐漸成為業界共識。當純粹的計算在邊緣轉向云邊協同,如何以云原生的方式構建一個跨越了邊緣和云端的分布式系統就成為了一個至關重要的問題:
(1)邊緣應用需要有完善的微服務治理能力,以滿足日趨復雜的邊緣業務模型;
(2)邊云、邊邊的協同成為邊緣應用的基本要求,以滿足海量邊緣數據的處理。
使用EdgeMesh可以支持跨越邊界的微服務訪問,EdgeMesh特性基于標準的istio進行服務治理控制,引入EdgeMesh-proxy負責邊緣側流量轉發以及P2P技術跨子網通信,提供云-邊、邊-邊通信,最終實現跨越邊云的一致的服務發現和訪問體驗。
a)邊邊協同
b) 邊云協同
邊緣設備管理:設備訪問微服務化
Kubernetes提供的設備插件(device plugin)框架, 旨在通過Kubelet管理“綁定”在節點上的硬件(加速器),例如:GPU、FPGAs、InfiniBand等,為Pod中的容器應用提供更強的計算和網絡性能。
而KubeEdge的設備管理關注的是與邊緣通信的外部設備,例如:藍牙終端、智能傳感器、工業設備等。KubeEdge對設備管理的實現采用的是Kubernetes官方推薦的Operator方式,并實現了設備孿生(device twin)。設備管理Operator的核心是Device CRD和Device Controller,其中Device CRD用來描述設備的狀態等元數據,Device Controller運行在云上,負責在云和邊之間同步設備狀態的更新(包括設備實際狀態和用戶設定的期望狀態)。
KubeEdge設備管理的工作流程如下圖所示:
Device Controller會把用戶設定的設備孿生期望狀態和配置下發到邊緣,而在邊緣的組件則要接收并處理這些信息。為了避免edge_core引入量處理邊緣設備通信的代碼,同時保持整個項目良好的易定制性,KubeEdge設計了一個邊緣設備驅動統一管理引擎Mapper。
Mapper之于KubeEdge的作用如同CRI之于Kubernetes,只是CRI作為Kubernetes定義的容器接口與底層容器引擎打交道,而Mapper作為一個開放接口方便不同的設備協議接入KubeEdge這個邊緣計算平臺。
KubeEdge v1.0中內置支持的設備協議是藍牙,后續版本將逐步增加對OPC-UA和Modbus的支持。有了Mapper的解耦層,用戶可以方便地根據實際需要開發自己的Mapper來實現與特定設備的通信,同時社區也歡迎廣大開發者貢獻更多的協議實現。
Mapper的架構如下圖所示:
歡迎加入KubeEdge大家庭
KubeEdge橫跨云原生和智能邊緣兩大版圖,擁有非常大的想象力空間,足夠給國內的優秀工程師們提供施展才華的平臺。我們希望借助KubeEdge開放的架構設計吸收更多全球開發者參與CNCF云原生社區,共同繁榮CNCF云原生和智能邊緣生態,協力一起將KubeEdge打造為中國在全球CNCF云原生社區以及智能邊緣領域生態的名片。
值得一提的是,KubeEdge項目來源于華為云上的明星服務智能邊緣平臺(IEF),當前IEF正處于公測階段,大家可以免費去體驗。
