KubeCon深度洞察 | KubeEdge開源首秀


以下內容根據華為雲DJ在KubeCon Shanghai Demo Session演講實錄整理而成。

KubeEdge Demo Show

11月15日上午Huawei宣布了KubeEdge項目開源,接下來我將公布KubeEdge這個開源項目的地址,並演示基於KubeEdge管理攝像頭的一個智能考勤系統的例子。

在此之前,先簡單介紹下KubeEdge這個項目背景。當前,越來越多的計算正在從雲端往邊緣側轉移。

 

 

我們身邊隨處可見邊緣計算的場景,例如:

  1. 智慧園區,可以在邊緣側完成提取視頻、圖片的摘要,圖像識別放在雲端。

  2. 工業機器人,需要在邊緣側進行消息預處理與模式匹配。

  3. 車聯網等等,需要在邊緣側進行ML模型預測等。

 

在我看來,5大現實場景下的“客觀因素”推動計算從雲端走向邊緣:

  1. 低延時要求。AR/VR的時延要求是ms級,工業控制的時延更是在us級。

  2. 高可靠性。具體表現為:>99.999%的可用性,響應時間可預測,響應結果可重復等。

  3. 本地自治。要求邊緣側可適應偶爾斷網,或者直接本地自治。

  4. 海量數據和有限帶寬的矛盾。設備側將產生海量數據,而以目前的帶寬還無法承載這數據量。另外一個事實就是,很多數據沒有全局價值,沒有必要浪費帶寬上傳到雲端。

  5. 信息安全。考慮到商業密碼和個人隱私,很多機構和個人並不願意把數據傳輸到雲端。

 

中心雲無法很好地解決以上問題,引入邊緣計算可以解決這些問題。那么如何在邊緣側部署應用呢?我們很自然地想到了Kubernetes。雖然Kubernetes已經成為事實上容器編排的標准,但是當涉到在邊緣側部署時,仍然存在不少挑戰。

 

例如:

  1. 邊緣側可能沒有足夠的資源運行一個完整的Kubelet;

  2. 當邊緣節點和雲端的網絡不穩定時甚至完全不通時,能否實現本地自治;

  3. 邊緣側節點之間通信;

  4. 如何在雲端管理多租戶的邊緣資源,包括設備;

  5. 邊緣側沒有serverless的支持,比如:函數。

 

為了解決Kubernetes在IoT Edge場景下的問題,Kubernetes社區最近成立了一個新的工作組:IoT Edge WG。

 

 

該工作組由Huawei,紅帽,Google和VMWare共同領導。這個工作組的目標是:

  1. 定義邊緣計算的常用術語;

  2. 梳理和解釋常見用例的架構;

  3. 在當前這些常見用例中梳理出可使用Kubernetes進行部署的用例及其面臨的挑戰;

  4. 提供一個能夠適應多種IoT Edge場景下的參考的架構。

 

因此,我們開源了KubeEdge,一個Kubernetes Native的邊緣計算管理框架,他的設計初衷就是:讓雲邊協同,計算下沉,讓雲端更加容易地管理邊緣節點和設備。

 

 

KubeEdge有以下幾個特點:

  1. KubeEdge構建在Kubernetes之上,100%兼容K8S API,可以使用K8S API原語管理邊緣節點和設備;

  2. 為了讓K8S應用能夠跑在邊緣上,深度定制和優化了runtime;

  3. 為了應對邊緣側的網絡不穩定因素,設計了可靠的消息通道;

  4. 邊緣適應本地自治;

  5. 豐富的應用和協議支持;

  6. 大大簡化了設備的接入復雜度;

 

現在,我公布KubeEdge項目開源地址:

https://github.com/kubeedge/

KubeEdge是個開放的社區,歡迎開發者積極貢獻代碼,在使用過程中有任何問題也歡迎提issue討論。

KubeEdge從功能上看,是打通了從底層設備到設備驅動/SDK,再到邊緣側Runtime,雲端控制器以及雲上應用整個軟硬件全棧。

 

從架構看,又分為雲端和邊緣側。邊緣側是單進程部署,采用了模塊化設計,由edged,metamanager,devicetwin,eventbus,edgehub這五個模塊構成,模塊之間通過golang的channel進行通信。

edged就是為邊緣計算深度定制的精簡runtime,雖然這是一個精簡的runtime,但它支持K8S的API原語,比如:Pod,Volume,Configmap等,同時也支持Pod探針和Event上報;

edgehub是一個web socket的client,負責和雲端的消息通信,包括:向邊緣側同步雲端資源更新,向雲端報告邊緣側節點和設備狀態更新;

metamanager則是一個消息處理器,是架在edged和edgehub之間的橋梁,同時也和后端data store交互,讀寫一些元數據;

EventBus則是邊緣節點和設備的之間的紐帶,他既可以從MQTT Broker處訂閱設備狀態更新事件,並向其他感興趣的組件發布,也可以向MQTT Broker發送對設備的操作指令,同時雲上app和用戶自己部署在edge的應用通信,也走eventbus;

 

DeviceTwin則負責存儲設備元數據到data store以及和雲端同步設備狀態,用戶可以從雲端下發的對設備操作指令發布給DeviceTwin。設備目前可以通過MQTT Broker注冊進來,也就是eclipse的mosquitto。未來,我們將支持更多的設備協議,例如:AMQP,BlueTooth,ZigBee等。

 

接下來我們將用一個智慧園區人臉考勤系統為例,展示KubeEdge協同管理雲,邊和設備的能力。

 

 

整個過程分為以下三個步驟:

  • 園區管理員通過KubeEdge納管邊緣計算節點,節點納管后,管理員可以通過界面對邊緣節點進行管理和業務發放;

  • 園區管理員通過KubeEdge統一管理、配置邊緣設備(如視頻攝像頭),並提供一套接口供邊緣應用使用,簡化應用配置;

  • 園區管理員通過智能視頻分析服務,部署邊緣人臉識別算法,在邊緣側完成實時視頻的人臉摳圖,然后在雲端完成人臉識別。

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM