華爲KubeEdge在邊緣計算的實踐

本篇文章是對華爲論文的翻譯，意在讓更多人瞭解到這個項目，讓更多的人瞭解到邊緣計算

摘要

在本文中，我們爲Edge-cloud通信和執行環境引入了Edge基礎架構（KubeEdge），我們將其視爲雲基礎架構的擴展。此邊緣基礎架構允許Edge採用現有云服務和雲開發模型，並提供邊緣和雲之間的無縫通信。KubeEdge包括一個名爲KubeBus的網絡協議棧，一個分佈式邊緣元數據存儲/同步服務和一個應用程序編排服務。KubeBus旨在擁有自己的OSI第2/3/4層協議實現，支持將雲端的邊緣節點和虛擬機連接爲一個VPN，併爲不同租戶的邊緣集羣提供通用的多租戶管理/數據平面。在Cloud和Edge中運行的服務在KubeBus之上相互通信，具有容錯性和高可用性。KubeEdge中的Edge元數據服務提供邊緣元數據存儲和服務，以在雲和Edge之間同步元數據，以支持邊緣節點脫機方案。KubeEdge包括Kubernetes [1]擴展，以便Kubernetes可以管理Edge Nodes以及Cloud中的VM，並部署/管理Edge Nodes的應用程序。

1 介紹

隨着邊緣設備的增加，我們更希望很多任務在本地執行，而不是上傳到雲數據中心。我們需要一種新型的計算範式，它能夠在網絡的邊緣執行任務，它就是邊緣計算。而在近幾年，隨着物聯網的發展，邊緣計算模型變得越來越重要。

在Edge計算中，最初在雲中運行的服務部署到Edge環境，並與其他Edge服務和雲服務協作。Edge服務調度，生命週期管理和監控可以從Cloud完成。例如，之前的研究[3]通過擴展現有平臺和優化的WAN環境算法推動了數據中心的計算。除了常見的數據處理這樣的數據過濾和聚合之外，AI過程也從數據中心推送到Edge，比如最近的研究[4]“在神經網絡層的粒度上劃分移動設備和數據中心之間的DNN計算”。

“雲計算是基於TCP / IP的高級開發和計算機技術的集成，如快速微處理器，巨大的內存，高速網絡和可靠的系統架構。”[雲計算的特徵]。有成熟的商業雲計算基礎設施來管理雲應用程序。例如，IaaS基礎設施OpenStack，Amazon EC2; 容器化應用管理系統Kubernetes [1]，docker swarm。

現有的雲計算基礎架構可能不會直接應用於Edge環境。這是因爲Edge環境與雲環境不同，涉及網絡連接/拓撲，網絡帶寬和相對受限的計算資源。例如，一個典型的Edge場景是多個Edge節點和雲通過廣域網（WAN）連接。邊緣節點在NAT後面的專用網絡中運行，因此在雲上運行的TCP客戶端無法連接到在Edge上運行的TCP服務; 此外，Edge和Cloud之間的網絡可能不穩定，在Edge運行的服務需要能夠脫機運行; 邊緣節點和雲之間的帶寬小於雲，並且更昂貴; 最後，一些邊緣節點具有約束計算資源，例如僅128 MB內存。

本文介紹了一種邊緣基礎設施，它支持邊緣節點的調度服務，與雲中的虛擬機相同，並考慮了邊緣環境特殊字符。Edge基礎架構基於以下3個組件：

• KubeBus將邊緣節點和虛擬機連接爲VPN，並將一個多租戶管理/數據平面連接到所有租戶的邊緣集羣;

• EdgeMetadataService，支持Cloud和Edge之間的元數據存儲和Edge和a-synchronization元數據;

• Kubernetes擴展，支持邊緣應用程序部署和生命週期管理。

該基礎架構適用於將基於微服務的應用程序從Cloud擴展到Edge。

本文的其餘部分安排如下。第2節討論邊緣計算基礎設施的相關工作; 第3節介紹了KubeEdge的架構和設計; 第4節KubeBus的實驗結果; 第5節討論未來的工作; 第6節總結了論文。

2 相關工作

在物聯網（IoT）時代，全球部署了數十億個傳感器和執行器。爲了管理物聯網設備並使用雲計算資源處理來自它們的數據，雲提供商提供的物聯網平臺包括Azure物聯網平臺，AWS IoT和Google IoT解決方案。物聯網平臺使用諸如Mqtt [9]或AMQP之類的發佈/訂閱代理來處理物聯網設備和雲服務之間的通信通道，例如Azure IoT中心。

物聯網設備數量巨大，物聯網數據太大，無法容納互聯網帶寬發送到雲端。雲提供商發佈Edge平臺，如AWS GreenGrass [5]和Azure IOT Edge [6]，以管理Edge端的IoT應用程序執行和IoT數據處理以及Cloud和Edge之間的數據傳輸。例如，GreenGrass將AWS Lambda函數環境擴展到Edge，以便Edge應用程序可以作爲Lambda函數部署到Edge並在Edge中進行管理。在AWS GreenGrass中，Edge服務通過Pub / Sub消息相互通信並與Cloud服務進行通信。Azure IoT Edge還具有Edge Hub，可將IoT Hub的功能擴展到Edge，併爲Edge服務提供Pub / Sub通信。在這個模型中，通過爲物聯網設備設計的類似通道，基於Pub / Sub sematic的中心雲邊緣節點通信。從Central Cloud的角度來看，Edge節點被視爲一種特殊的IoT設備。

服務，每個服務都在自己的進程中運行，並與輕量級機制通信，通常是HTTP資源API。要將基於Micro-service的雲應用程序擴展到Edge，一個應用程序的部分小型服務將部署在Edge Nodes中。邊緣服務應該與雲中的相同RPC以及其他雲服務相互通信。爲實現此目標，Edge平臺需要提供與雲相同的執行環境。在環境中，無論服務是在Edge還是Cloud中運行，服務都可以在一個集羣中相互通信。此外，微服務應在Edge節點和具有相同部署基礎架構的雲之間自由調度。

發佈/訂閱協議可能不適合將微服務從Cloud擴展到Edge。由於跨微服務RPC可能不是發佈/訂閱協議，因此基於發佈/訂閱協議的邊緣計算基礎結構中運行的服務需要重構以滿足基礎結構要求。

KubeEdge爲Cloud和Edge環境構建了一個同構執行環境。它解決了KubeBus的邊緣節點連接拓撲問題，它將端口中的邊緣節點，虛擬機和容器網絡連接爲VPN; 它還包括一個Kubernetes擴展，可將Kubernetes功能擴展到Edge環境，以便Edge服務可以像Cloud一樣部署到Edge; KubeEdge通過EdgeMetadataService減輕Edge與雲的不穩定連接，EdgeMetadataService在Edge提供元數據存儲，在Cloud和Edge之間提供元數據同步。下一節將爲他們提供詳細設計。

3 架構和設計

圖1 KubeEdge架構
KubeEdge提供了一個多租戶的Edge基礎設施。就像圖1中所描述的那樣，在雲數據中心一側，它包括多租戶的管理/數據平面，並且還有多個租戶的集羣。多租戶的管理/數據平面包括雲中心的KubeBus以及租戶管理功器。一個租戶集羣包括在邊緣區域運行的一個或多個邊緣節點，以及在雲中運行的一個Kubernetes集羣。Kubernetes集羣包括Kubernetes主機和多個虛擬機。Kubernetes master將vm和邊緣節點都作爲正常的Kubernetes節點。

每個邊緣節點中都運行一個KubeEdge代理。KubeEdge代理包括提供邊緣網絡接入的KubeBus、提供邊緣連接元數據存儲和同步服務的EdgeMetadataService;以及管理Edge應用程序生命週期的AppEngine。AppEngine是運行在Edge上的輕量級Kubelet。

在雲區域，對於每個租戶的Kubernetes集羣，在一個VM節點上運行一個KubeBus虛擬路由器，路由邊緣節點子網與VM子網/容器網絡子網之間的流量;KubeMaster中還運行着一個EdgeController，用於在KubeMaster和edge節點之間交換邊緣服務配置和狀態。

3.1 KubeBus

在KubeEdge環境中，一個服務既可以調度到雲上的VM當中，也可以調度到邊緣節點，邊緣節點的服務使用與雲環境相同的RPC與其他服務通信。KubeBus是爲了解決邊緣服務與雲服務之間的通信問題而設計的，邊緣服務運行在邊緣節點上，而云服務運行在雲環境中的容器網絡上。KubeBus還支持針對多個租戶的單個管理/數據平面，並提供Http。從邊緣節點發布WebService。

3.1.1 Edge Node VPN

KubeBus的第一個功能是連接在邊緣虛擬私有網絡中的邊緣節點。在一個典型的邊緣環境中，不同的邊緣節點運行在不同的私有網絡中，沒有公共IP地址，只能通過NAT連接到雲端，兩個邊緣節點之間沒有直接的網絡連接。兩個邊緣節點的通信需要通過KubeBus@Cloud進行路由。KubeBus是3層的覆蓋網絡。如圖2所示，KubeBus通過TCP連接實現OSI網絡模型的L2和L3。KubeBus數據鏈路層在Edge節點和KubeBus@ cloud之間創建一個或多個長期運行的TCP連接。KubeBus還包括一個TUN接口，它接受來自操作系統內核的IP包。IP包通過L3和L2傳遞到KubeBus@Cloud，然後KubeBus@Cloud通過長期運行的TCP連接路由到目標邊緣節點。

圖2 KubeBus VPN通信

3.1.2 將邊緣節點VPN與容器網絡連接

KubeBus的第二個功能是使Edge服務運行在與運行在VM網絡或容器網絡(如flannel)中的雲應用程序相同的網絡中。
圖3 KubeBus Edge/VM/container 網絡VPN

在KubeEdge環境中，有3個子網絡。同屬於一個租戶的所有邊緣節點屬於一個Edge節點子網，這個子網是KubeBus創建的VPN網絡，如3.1.1所示;在VM集羣中，所有VM都屬於VM子網;VM集羣中運行的所有容器都屬於容器子網。KubeBus將它們作爲單個VPN連接。

如圖3所示，安裝了一個KubeBus虛擬路由器代理在VM集羣中的一個VM上。KubeBus虛擬路由器代理包括KubeBus網絡協議棧，在邊緣節點子網和VM子網下充當路由器。由於VM子網可以訪問容器子網，當在每個VM節點和邊緣節點中配置正確的路由時，邊緣節點子網最終連接到容器子網(注意:對於具有地址過濾策略的集羣，需要額外的覆蓋)。

3.1.3 多租戶管理/數據平面和服務發佈

KubeEdge是一個多租戶基礎設施。不同租戶的邊緣節點由多租戶管理/數據平面管理。一方面，所有租戶的管理/數據平面服務與邊緣節點之間存在通信;另一方面,不同租戶之間的邊緣節點應當隔離。和現在的VPN解決方案不同，KubeBus構建一個KubeBus堆棧構建Http層 ,使邊緣節點之間的通信和多租戶管理/數據平面。根據網絡服務運行在邊緣節點可以從平面管理/數據訪問服務,反之亦然。除此之外，在Edge節點上運行的Http web服務也可以通過多租戶管理/數據平面發佈到Internet上。它對於某些客戶場景非常有用。例如,一個邊緣節點與攝像機可以發佈Http視頻流作爲Http WebService 發送到KubeBus並且暴露到多租戶管理/數據平面,然後等互聯網瀏覽器的Http客戶端可以得到視頻流從Http WebService邊緣節點上運行。
圖4 KubeBus Http協議棧
如圖4所示，通過KubeBus的不可靠網絡層3，構建了連接可靠的KubeBus傳輸層4。KubeBus L4提供與TCP相同的API接口。如聽/接受/連接/斷開連接。在KubeBus L4上，運行着2個“Http反向代理”:KubeBus客戶機代理和KubeBus服務器代理。

• KubeBus客戶端代理監聽TCP端口，當接收到Http客戶端請求時，通過KubeBus L4可靠連接將請求轉發給KubeBus服務器代理;

• KubeBus服務器代理在KubeBus L4上偵聽，當收到由KubeBus客戶端轉發的HTTP請求後，它將依次轉發請求目標本地Http WebService。之後，Http響應將通過服務器代理和客戶端代理返回到Http客戶端。

使用KubeBus客戶機和服務器代理，構建了另一個“KubeBus之上的Http層”。運行在雲或邊緣節點上的Http web服務可以註冊到KubeBus，並且Http客戶端可以從雲、邊緣節點或Internet來訪問服務。

來自雲或不同邊緣節點的不同租戶的Http web服務可以註冊到KubeBus。一個web服務被標識爲<Tenant ld, Edge節點名，WebServiceName>。租約是租戶的全局標識符;邊緣節點名是租戶範圍內唯一的邊緣節點名;Web服務名稱是節點級別的惟一服務名稱，KubeBus使用全局標識符URL模式來標識Htp Web服務(如圖5所示)。

3.2 邊緣元數據服務

由於到雲的邊緣節點是WAN連接的，所以連接可能是不可靠的並且帶寬低和價格昂貴。

• 爲了解決廣域網的可靠問題，邊服務是要求自動運行。邊緣的服務即使是邊緣節點也需要重新成功運行重啓後離線。因此，邊緣服務的配置需要在邊緣節點中保持持久性，當邊緣結點和雲中心的連接恢復之後，配置可以從雲同步到網絡邊緣；
• 爲了解決廣域網的低帶寬問題，數據爲同步配置傳輸的卷應被減到最小。因此,增量同步比完整快照更合適。不僅配置需要從雲傳送到邊緣，邊緣服務的狀態也需要從邊緣傳送到雲。

邊緣元數據服務是爲這兩個需求而構建的。邊緣元數據服務包括在邊緣端運行的元數據存儲和同步服務(SyncService)，在雲端也有相應的元數據存儲。將邊緣服務的配置寫到雲端元數據存儲中，使配置更改過程作爲異步過程進行。即使邊緣脫機，寫操作仍然成功;當邊緣節點和雲之間的網絡連接恢復後，Sync服務從雲元數據存儲請求自上次成功同步以來的配置更改，並將其寫入本地元數據存儲。同步最終應該是一致的。因此元數據存儲需要支持原子寫和增量檢索。

KubeEdge選擇Etcd[8]作爲元數據存儲。這是因爲Etcd支持事務性寫，並且有多個版本併發控制API接口來檢索增量更改，即基於修訂的Get/Watch方法。

圖6 配置同步算法

從雲到邊緣的配置同步算法如圖6所示。同步過程是一個循環。循環有3個步驟。首先，從邊緣節點本地Etcd存儲中讀取上一次成功同步的最後一個同步修訂(LSR);第二，LSR後的更改和新修訂來自雲Etcd Store;最後，將修改的內容和新的修改內容寫入邊緣節點本地Etcd存儲區。寫中的新修訂將在下一次循環迭代中成爲LSR。該算法在同步過程崩潰的任何時刻都能實現最終的一致性和原子性。因爲只有更改的數據需要同步，同步所消耗的帶寬被最小化。邊緣到雲的服務狀態同步算法與之相似。

3.3 Kubernetes 邊緣擴展

在每個節點上運行一個代理(Kubelet)。它從KubeMaster獲取應用程序配置，管理應用程序生命週期，並向KubeMaster報告應用程序的狀態。Kubernetes邊緣擴展是爲了解決邊緣環境中WAN網絡連接的特定特性而設計的。它將Kubelet分爲兩部分:EdgeController在雲端運行，AppEngine在邊緣節點運行。EdgeController用代表邊緣節點向KubeMaster索取應用配置;然後通過EdgeMetadataService將更改後的配置傳遞給AppEngine;之後，AppEngine將基於存儲在EdgeMetadataService中的應用程序配置來處理應用程序生命週期。AppEngine還將通過EdgeMetadataService和EdgeController向KubuMaster報告應用程序狀態。由於雲和Edge之間的數據交換是建立在EdgeMetadataService上的，所以可以在異步模型中完成，只需要傳遞更改即可節省帶寬。

4 實驗

我們在測試環境中評估了KubeEdge的性能，如圖7所示。KubeMaster和VM1/VM2在一個子網中運行，Edgel和Edge2在不同的子網中運行。他們都是通過互聯網連接到KubeBus@Cloud的。KubueBus@Cloud在AWS的一箇中央虛擬機中運行。
圖 7 實驗性能測試環境
我們用Ping測試了它們之間的網絡延遲。測試結果如圖8所示。
從結果可以看出，邊緣與vm之間的延遲主要來自internet延遲。KubeBus對延遲的影響非常小。

基於此，我們比較了邊緣節點和VM之間的部署延遲。我們只測量KubeMaster獲取部署請求和Kubelet/AppEngine獲取結果之間的延遲。VM的延遲約爲2秒，而邊緣的Edee延遲爲3秒。我們可以看到Edse對部署延遲的影響的延遲是可以接受的。硬件的配置信息如下所示：
圖9 硬件配置

KubeEdge作爲雲的擴展構建了一個基本的邊緣基礎設施。它假設邊緣節點需要通過雲進行通信。事實上，邊緣節點之間可能是直接連接的，而邊緣節點可以作爲集羣工作，即使與雲中心斷開連接也是如此。計劃使用以下特性來增強啓用邊緣集羣的功能。

1.邊緣網絡：KubeBus爲邊緣節點和雲中的容器網絡創造了一個VPN環境。在當前的模型當中，邊緣節點間的連接將通過KubeBus@Cloud進行。兩個邊緣節點之間可能存在直接連接。例如，邊緣節點可能具有公共IP地址，以便另一個邊緣節點可以直接創建到它的TCP連接;2個邊緣節點也可以建立基於TCP洞穿技術的直接連接;或者兩個邊緣節點之間可能存在專用連接。通過直接連接，邊緣網絡拓撲結構將是一個非集中式網格網絡。KubeBus需要支持邊緣網駱的創建，如TCP穿孔和高效的包路由等。

2.去中心化的邊緣元數據服務:邊緣網絡將是一個去中心化的邊緣網格網絡。當與雲的連接不可用時，邊緣節點之間的連接可能仍然有效，邊緣節點之間仍應相互協作，高效工作。在邊緣網格網絡中，爲了實現邊緣節點之間的元數據交換，需要對邊緣節點進行去中心化的EdgeMetadataService。例如，邊節點可以通過連接到另一個邊節點來連接邊網格網絡。在decentraledgemetadataservice支持下，雲脫機時，到新邊緣節點的路由應該傳播到其他邊緣節點。

3.去中心化邊緣集羣:基於邊緣網格網絡，當中心雲作爲一個集羣脫機時，邊緣節點需要自主工作。考慮到網絡拓撲、資源限制和預先配置的任務優先級，在一個邊緣節點上運行的服務可以重新調度到其他節點上，以實現負載均衡、可靠性。爲了實現這一目標，需要對邊緣集羣進行去中心化。

5 conclustio

隨着更多的數據從邊緣端生成，更多原本在雲中執行的計算將被推送到邊緣端。邊緣環境在網絡拓撲、連接和性能方面與雲不同。邊緣基礎設施是推動雲計算高效邊緣的關鍵。本文提出了KubeEdge作爲一種邊緣基礎設施。基礎設施被認爲是雲基礎設施的擴展。它通過將雲中的邊緣節點和VM作爲單個集羣連接起來，構建了與雲類似的邊緣執行環境。它可以替代現有的基於發佈/訂閱的邊緣基礎設施。