首頁 > 運動

雲原生邊緣計算:探索與展望

由 邊緣計算之家 發表于 運動2022-11-28

簡介硬體低耦合的輕量級雲原生支撐技術(如容器)較契合邊緣計算的資源特徵,容器(如Docker)能夠輕量級地實現多個使用者之間的隔離,進而實現資源的彈性伸縮管理以及應用的註冊、發現、編排、釋出,提升應用開發執行效率

world怎麼降級為正文

本文首發於《物聯網學報》2021年3月第5卷第1期,邊緣計算社群經過物聯網學報授權,釋出本文。

本文是國家自然科學基金資助專案(No。61772480,No。61972171);之江實驗室開放課題(No。2021KE0AB02)。

本文作者:曾德澤,陳律昊,顧琳,李躍鵬.

以下為正文,總共14600多字,預計閱讀36分鐘,建議收藏儲存!

摘 要:

雲原生計算基於低開銷容器化的執行方式非常契合邊緣計算,因此,提出將雲原生技術應用於邊緣計算, 發揮雲原生的優勢,使資源管控對應用開發部署透明化。考慮相較於雲計算,邊緣計算具有資源廣分佈、高異構、 多碎片特徵,亟需算網協同的資源管控。根據雲原生相關技術的發展現狀,整合軟體定義網路與網路功能虛擬化等未來網路技術,提出

全棧式雲原生邊緣計算架構

。在此基礎上,考慮容器的層次化特性,提出適用於有限邊緣計算資源的低開銷容器部署方法,分析探討雲原生邊緣計算所面臨的挑戰。

關鍵詞:雲原生;邊緣計算;容器;微服務

1 引 言

為了應對海量終端快速增長的高算力需求,透過計算解除安裝等方法利用雲計算的海量計算資源被廣泛認可。但“端-雲”間高時延難以滿足諸多實時應用的低時延要求,邊緣計算概念應運而生。邊緣計算透過將計算需求轉移至靠近使用者的一側,利用網路邊緣的計算資源承載雲計算服務,利用“資料上行、計算下行”的方式,突破了“終端+資料中心”兩級架構的侷限性,可以滿足應用對時延與頻寬的需求

[1-3]

邊緣計算利用其獨特的地理位置優勢以低時延、高頻寬的方式提供資訊科技服務環境和雲計算能力,被視為物聯網、5G、大資料、人工智慧等領域的關鍵支撐技術之一,共同促進著工業網際網路、車載網路、智慧駕駛、虛擬現實/增強現實(VR/AR,virtual reality/augmented reality)、智慧醫療等行業產業的變革

[4-5]

。特別是隨著6G被提上日程,

利用邊緣計算發展邊-端融合系統,透過算網融合排程最佳化來發揮6G的超低時延優勢,被視為未來計算的新興發展趨勢[6]

。計算優先網路

[7]

、算力網路

[8]

、多接入邊緣計算

[9]

等邊緣計算相關概念與技術,說明了邊緣計算在未來網路與計算中的重要性,引發了各行各業的廣泛關注。

從產業現狀看,阻礙邊緣計算發展的主要因素之一是邊緣服務的開發、管控以及邊緣應用生態的構建。儘管邊緣計算資源管理與任務排程最佳化已經得到廣泛研究和關注

[9-10]

,截至目前,業界尚未有一套統一標準的資源管理與任務管理框架。

儘管邊緣計算與雲計算具有高度的相似性,但由於其資源異構、裝置分佈廣、資源碎片等特點,傳統雲計算解決方案(如OpenStack)在應用於邊緣計算過程中存在諸多不適與侷限,包括:

1)複雜性,邊緣裝置能力差異大、網路接入方式多、型別多樣的終端裝置和服務需求的不同導致複雜性大;

2)難預測性,終端裝置的移動性和隨時間變化的任務需求使得難以預測;

3) 不確定性,邊緣裝置的資源異構性和任務負載的動態變化造成服務需求的不確定性;

4) 高動態性,雲資料中心內在的資料和服務按需下行需求造成高動態性。

透過上述分析表明,打造邊緣計算平臺的“作業系統”勢在必行。

儘管存在差異,雲計算的發展歷程仍為邊緣計算提供了參考與借鑑,諸多解決方案已嘗試將雲計算相關框架與技術遷移至邊緣計算,並根據邊緣計算特點進行定製改進,如針對邊緣計算資源廣分佈的特徵對OpenStack 進行定製化改進

[11]

。近年來,雲原生正逐漸成為雲計算的發展主流。以Kubernetes為代表的雲原生編排系統,被廣泛認為將成為分散式系統的核心作業系統。雲原生透過容器化、微服務化、松耦合化服務,實現基於服務的快速按需應用編排構建,滿足快速迭代的需求驅動應用開發模式,成為軟體開發的主導力量

[12]

邊緣計算作為雲計算的拓展,也可有類似的發展思路。硬體低耦合的輕量級雲原生支撐技術(如容器)較契合邊緣計算的資源特徵,容器(如Docker)能夠輕量級地實現多個使用者之間的隔離,進而實現資源的彈性伸縮管理以及應用的註冊、發現、編排、釋出,提升應用開發執行效率。此外,相較於雲計算,邊緣計算的異構性更高,其資源形態多樣、網路接入多樣、訪問特徵多樣,由應用開發執行維護人員直接管理物理資源,挑戰大、效率低。

因此,透過容器抽象資源,讓資源管控對應用開發執行維護人員透明,具有十分重要的意義,將雲原生應用拓展至邊緣計算平臺,已經得到了學術界和業界的認可。現在已有一些針對邊緣環境的解決方案,如Kubernetes的簡化版K3s和華為技術有限公司於2018年釋出的Kubernetes原生邊緣計算平臺KubeEdge等框架,迅速得到了業界的廣泛認可。

雲原生邊緣計算透過容器等支撐技術實現了底層物理計算資源的抽象與軟化,解耦軟體開發執行維護與底層資源管控。事實上,除了計算資源以外,網路資源管控也是邊緣計算需要考慮的另一個重要方面。相較於雲計算,邊緣計算網路異構性更強,表現在接入方式(有線與無線並存)異構、頻寬異構、可靠性異構等多個方面。同時,邊緣計算具有非規則的網路拓撲。邊緣計算是移動網際網路的重要支撐,移動網際網路的蓬勃發展對邊緣計算的資源管控提出了更高的要求。

從網路角度看,鄔江興院士指出:網際網路的多元化發展,導致當前僵化的網路執行機制下傳輸控制、資源管理、配置維護等複雜性倍增,網路效率低下,使用者體驗差

[13]

。針對該問題,以軟體定義網路和網路功能虛擬化為代表的未來網路技術以網路開放為目標,打破傳統剛性的網路架構和基線技術對網路多元化發展、個性化服務、創新應用發展的制約。軟體定義網路和網路功能虛擬化事實上實現了網路層的軟化,透過軟化實現開放,進而支撐定製創新,在雲計算中已得到了廣泛認可與應用。

綜合當前邊緣計算的發展困境以及雲計算的前沿發展趨勢,本文認為軟化是推動邊緣計算發展的潛在思路。本文將雲原生技術以及未來網路技術融合,提出了全棧式雲原生邊緣計算架構,實現算網融合的資源管控。針對邊緣資源有限特徵,透過發掘利用容器的分層結構特徵,研究了低開銷的邊緣服務部署最佳化方法。最後,對雲原生邊緣計算將面臨的發展挑戰進行展望。

2 雲原生計算的發展現狀與趨勢

2.1 雲原生架構:微服務和無伺服器計算

雲原生計算

[14]

透過引入靈活的網路資源排程方式,實現動態的資源編排,成為雲計算網路開發和軟體部署最快速有效的方式,得到了業界的廣泛認可。雲原生計算基金會定義雲原生計算的特徵屬性為:面向微服務、基於容器化封裝和自動化管理。在雲原生的架構中,應用程式被開發為無狀態和鬆散耦合的微服務,從而提高服務的重用性和可靠性。

以雲原生的方式對應用進行執行維護具有諸多優勢,能夠適應DevOps模式、持續整合等應用研發需求。如當一個服務例項在執行中失效時,另一個服務例項可以快速生成並立即頂替其功能;當服務請求劇烈變化時,能夠靈活地實現服務例項的縮放,提高資源利用率,保障使用者服務質量。接下來,簡要介紹雲原生計算的架構與支撐技術。目前,雲原生計算主要有微服務和無伺服器計算兩種主流架構

[15]

微服務透過將一個大型單體應用分解為多個 小型模組來進行部署,這種方法的好處是可以構建、測試和部署單個服務,不會對整個產品或其他服務產生不良影響

[12]

。微服務能夠實現更便捷的釋出,開發者可以在最初只向子集釋出新特性,然後在該特性達到目標期望後轉向整個使用者群釋出新特性。微服務所具有的敏捷性、可靠性和可伸縮性很契合應用開發執行維護的需求。

無伺服器計算是將基礎設施伺服器層抽象出來的概念

[16]

,這樣可以幫助開發人員專注於構建應用,不必考慮硬體伺服器的可伸縮性、可用性和安全性。從使用的角度來看,應用程式應儘可能多地使用網路和儲存,這意味著當程式沒有被使用時,硬體資源不會被閒置;當使用量激增時,基礎設施可以在任何程度上擴充套件,而不必立即手動提供新伺服器

[12]

微服務體系結構允許小團隊的開發人員專注 於單獨的服務,每個團隊提供一個特定的任務,而無伺服器計算則幫助團隊以最少的精力啟動和執行這些微服務。微服務仍涉及一定量的計算資源叢集管理

[12,17-18]

,而無伺服器計算使得應用開發者可以專注於程式碼編寫並定義應該觸發程式碼執行的事件,並將其留給雲來處理其餘的事。

2.2 雲原生支撐技術

雲原生的出現需要開發者提出新的協議及架 構,一些比較成熟的技術如容器

[12]

、微服務排程工具(如Kubernetes)、服務網格等,為雲原生的實現提供了巨大的技術支援與經驗。雲原生的關鍵支撐技術如下。

1)容器

容器的本質是一個程序,透過對該程序進行隔離和資源控制,使得其在執行時不會相互干擾。同時,容器具有良好的移植性,可以在不同的作業系統中良好執行。以前,開發者通常會使用虛擬機器來完成某些功能,但是虛擬機器的系統開銷較大,並且不利於程式的移植與部署。與虛擬機器相比,容器更加輕量化,打包下載都更方便,其中最著名的容器是Docker。Docker是一個開源容器引擎,可以讓開 發者打包其應用以及依賴包到一個輕量級、可移植的容器中,然後釋出到任何流行的作業系統中。在執行時,Docker的效能開銷幾乎可以忽略不計。Docker佔用資源少、部署快,每個應用可以被打包 成一個Docker映象。Docker容器中每個應用不需 要與其他應用組合,也不依賴於生產環境基礎結構,能在研發、測試、生產過程中為應用提供一致的環境。Docker使用客戶端—伺服器模式,利用遠 程應用程式介面(API,application programming interface)來管理和建立Docker容器。Docker容器透過Docker映象來建立,映象就像容器的模板,每次建立容器都依賴於已有的映象。

2) 容器管理器

僅依靠容器並不能滿足開發者的需求。現在,一個叢集中有上萬個容器映象是很普遍的,為了管理這些容器,如控制容器的生存週期,對容器進行遷移,對這些容器間的流量進行排程等,開發者需要一個完備的治理框架,目前Kubernetes是應用較廣泛的治理框架。Kubernetes簡稱K8s,是一個可移植、可擴充套件的開源平臺,用於管理基於容器的微服務叢集。在 Kubernetes 中,可以建立多個 Pod(Kubernetes的基本單元),每個Pod中可以部署多 個容器,每個容器中可以部署一個服務,然後透過內建或自定義的負載均衡策略,實現對一組微服務的管理、註冊和訪問。開發者可以使用Kubernetes的kubectl元件對其下的各個服務進行管控。

3) 服務網格

儘管在很多情況下Kubernetes能夠完成微服務治理功能,但開發者仍然會遇到其他問題。在實際生產環境中,由於微服務的實現方式不同,如果要使微服務之間進行通訊,開發者需要預先協調通訊介面和方式。此外,流量的管控與排程由於要考慮環境中的各種因素,所以開發過程並不簡單。因此, 服務網格應運而生

[19]

。Kubernetes與服務網格對比如圖1 所示,作為服務之間通訊的基礎設施層,服務網格可以分離微服務中的通用功能,如服務註冊發現、負載均衡、熔斷降級、流量管理、監控等功能,極大地補充了Kubernetes使用時的一些不足。

雲原生邊緣計算:探索與展望

在服務網格中,每個微服務透過邊車代理其服務間通訊,因而大量的微服務與對應的邊車會表現出網格的形式,這就是服務網格名稱的由來。服務網格可以在多種環境中部署,最常用的是Kubernetes。服務網格(如Istio框架)與Kubernetes 有較好的相容性,Kubernetes對應用進行生命週期管理,服務網格提供應用間的流量、安全管理以及可觀察性。

雲原生支撐技術框架對比如圖2所示,Kubernetes的Kube-proxy元件實現了流量在Kubernetes服務中多個Pod例項間的負載均衡,但是Kube-proxy的設定是全域性的,無法對單獨的Pod 進行精細的管理。而服務網格將Kubernetes中的這 一功能分離出來,部署在邊車中,不再需要Kubernetes的Kube-proxy元件支援,透過更接近微 服務應用層的部署來管理服務之間的通訊、流量管理、負載均衡和可觀察性。總體來講,Kubernetes使用Docker容器技術來部署和管理微服務,實現微服務的自動部署、自動重啟、自動複製、自動擴充套件等功能,服務網格則可以部署於Kubernetes上,負責提供應用間更靈活的流量控制、安全管理以及可觀察性。

雲原生邊緣計算:探索與展望

4)Unikernel

Unikernel是一個特殊的、單地址空間的機器映象,它實現了底層硬體資源的直接取用,免去了不必要的硬體抽象。Docker是一種有效的應用管理容 器技術,它解決了應用的可移植性問題。相比於虛擬機器,Docker的映象已經小了很多,但還是有好幾百兆。Unikernel則進一步減小了自身的體積,只需要幾十兆甚至幾兆。Unikernel在構架中去除了作業系統,其應用直接執行在hypervisor或者硬體上,由於不包含許多應用不需要的包和依賴,從而有效改善了資源的利用情況。Unikernel具有以下優勢:

①體積小,Unikernel只需要包含應用所必須的依賴和包,大大減小了自身的體積;②速度快,由於Unikernel中沒有其他不必要的程式,有效減少了多程序之間的任務切換和啟動,使得中央處理器(CPU,central processing unit)能夠高效執行,啟動速度也非常快,通常只有20mm甚至幾毫秒,使它在使用者需要時進行啟動響應。Unikernel也由此被視為實現雲原生的重要支撐技術之一。

2.3 雲原生邊緣計算

雲原生助力邊緣計算,已經得到了工業界的認可,出現了一些應用較廣泛的框架,如阿里雲開源的專案OpenYurt。OpenYurt是基於原生Kubernetes構建的框架,使用者可以使用OpenYurt在 邊緣環境中管理執行的微服務。它克服了一些邊緣場景的限制,例如,如何最小化裝置和工作負載之間的長距離網路流量,如何解決邊緣場景中的可靠性,如何進行安全驗證,如何降低傳送時延等。OpenYurt提供了完全的Kubernetes API相容性,支援Kubernetes的所有特性,它也提供了一種工具可以讓本機的Kubernetes轉化為邊緣狀態,還能提高叢集在邊緣場景中的穩定性。

KubeEdge是雲原生在邊緣計算中拓展的典型架構,其基於Kubernetes架構提供了許多邊緣場景的功能支援,如離線執行能力、邊雲協同能力等。該架構分為雲端元件和邊緣元件。在雲端元件中,使用者透過kubectl命令列對目標物件的預期狀態發出命令,並由Kubernetes的API伺服器進行接收並使用排程器對物件進行排程;在邊緣元件中,所有元件設計的原則為“簡單至上”,以降低邊緣元件的資源佔用、發生故障的機率以及維護的難度。

K3s是另一種經典的被運用在邊緣計算中的架構,傳統的Kubernetes其元件很臃腫複雜,導致其在邊緣裝置效能不足的背景下工作較困難,而K3s僅作為單一的二進位制檔案進行打包和部署,安裝迅速便捷。同時,K3s刪除了很多對於執行最低限度的叢集來說不重要的元件,加入了一些新的必要元素,使得其可以適用於邊緣計算場景。

儘管現在已經有一些架構可以幫助開發者應對邊緣場景,但這些架構仍然存在一些問題,它們大多隻考慮了邊緣環境的一部分,如只考慮了服務治理,而忽略了網路協議等也是可以融合的。因此,本文將進一步地將服務網格、軟體定義網路、網路功能虛擬化等技術融合,提出全棧式架構。

03

全棧式雲原生邊緣計算架構

雲原生計算變革了應用開發與運維模式,透過底層物理計算資源的抽象與軟化,使得應用開發執行維護人員集中關注應用自身,不需要考慮底層物理資源。同時,針對傳統網路架構剛性基線技術對網路靈活管控的侷限、對網路資源與計算資源協同排程的制約,以軟體定義網路與網路功能虛擬化為代表的未來網路技術提供了新的解決途徑。融合雲原生計算與未來網路技術,本文提出了面向邊緣計算的全棧式雲原生計算架構,實現邊緣網路資源、 計算資源的協同管理,全棧式雲原生邊緣計算架構如圖3 所示。當前分散式計算系統結構的發展趨勢是資料層與控制層的分離,如軟體定義網路透過解耦並集中控制層面,極大地提升了計算機網路的靈活性和可定製性;服務網格提供控制器管理邊車所代理的服務的流量。因此,本文認為,

解耦資料層與控制層是未來分散式系統架構的發展趨勢之一。

圖3中所提出架構的最上層為控制層,包含面向多個不同功能元件的控制器;控制層的各個控制器元件管控其下各層的不同元件。

雲原生邊緣計算:探索與展望

圖3 全棧式雲原生邊緣計算架構

1) 物理層

物理層是整個系統的最底層,包含各種邊緣計算物理資源,如計算機、網路裝置、通訊裝置、感測裝置、儲存裝置等。從資源型別來看,邊緣計算與支撐雲計算的資料中心類似。但

從資源特徵來看,邊緣計算與雲計算有很大區別,主要表現在資源高異構與廣分佈兩個方面。

雲計算資料中心一般由單一的主體執行,其物理裝置相對比較統一。由於邊緣計算接入門檻低,各類主體均可提供基礎物理設施接入邊緣計算平臺。如移動運營商可透過靠近蜂窩網通訊基礎設施的計算裝置接入邊緣計算提供物理資源,城市中的小區也可建設小型資料中心。各基礎設施提供商的物理資源難以統一,不僅表現在資源容量方面,同時表現在資源架構方面。如計算機可能為X86架構,也可能為ARM(advanced RISC machine)架構,且同時可能部署不同的硬體加速器,如圖形處理器(GPU,graphics processing unit)、現場可程式設計邏輯閘陣列(FPGA,field programmable gate array)等。

此外,由於邊緣計算靠近終端使用者,其網路接入方式更多樣,不僅包括有線網路接入,還包括各類無線網路接入(如4G、5G、Wi-Fi 等)。多元化基礎設施的提供,不僅引發了邊緣計算的高異構,同時也導致了資源分佈廣的特徵。因此,邊緣計算不具備雲計算資料中心相對規則的網路拓撲(如FatTree、Bcube等),其網路拓撲由於地理分散式的計算資源供給具有非規則屬性。因此,物理資源的高異構與廣分佈對資源管控帶來了極大的挑戰,阻礙了邊緣計算的發展。抽象廣分佈的異構物理資源,使得邊緣計算物理資源特徵對應用開發執行維護透明,對邊緣計算的發展有重要推動作用。

2) 網路層

由於物理層資源的廣分佈特徵,使得網路成為串聯各類異構資源的核心。同時,如前所述,傳統封閉剛性的網路技術阻礙了邊緣計算應用的開放式發展。因此,在本文提出的全棧式網路架構中, 為實現算網協同的資源排程,單獨抽象一層獨立的網路層。網路層不僅包括交換機、路由器等基礎通訊物理設施,還包括驅動軟體定義網路功能實現的各類基礎軟體(如Open vSwitch等)以及各類虛擬

網路功能。

軟體定義網路透過將控制平面從資料平面中分離出來,使開發者在不改變硬體裝置的前提下,可以更靈活地進行網路管理,從而實現對上層應用(或服務)間的開放式流量管理與個性化定製。同時,透過網路功能虛擬化技術為應用間的流量管理提供各類網路服務。透過將傳統基於硬體實現的各類虛擬網路功能軟化,使網路裝置功能不再依賴於專用硬體,從而實現對各類網路服務的靈活管理、新業務的快速開發和部署。

3) 服務層

服務層直接採用雲原生計算架構,其核心是在物理計算資源上抽象出各種服務構建邊緣應用。因此,服務層同時涉及容器與虛擬機器兩種虛擬化技術。首先,與雲計算資料中心類似,以虛擬機器的形式抽象物理計算資源,提升物理資源利用率。在虛擬機器中,可進一步地部署容器用於服務例項的實現與部署。通常情況下,一個容器不能滿足一個微服務的所有需求,因此主流的容器管理器(如Kubernetes)會將一些容器聯合起來,將其稱為Pod, 並將Pod 作為最基礎的處理單元,即服務例項。

此外,在邊緣計算場景中,由於資源限制,並非所有計算裝置都適合部署虛擬機器進行物理資源共享。因此,Pod及其所包含的各類容器也可以直接部署在物理伺服器上。無論Pod 部署在虛擬機器上還是物理 伺服器上,均對應用的開發與執行維護透明。也就是說,邊緣應用開發執行維護人員的關注物件為Pod或由Pod提供的基礎服務,不需要關注物理資源的管控,後者由邊緣設施提供商進行執行維護。

特別注意的是,在本文提出的全棧式架構中,引入了服務網格實現異構服務間的標準化流量通訊管理。如前所述,每個服務將對應一個邊車,邊車與軟體定義網路的資料平面融合,共同構成本文框架中的資料層部分。透過融合,使得網路層的軟體定義交換機中的流表能夠根據服務的屬性資訊(如服務名、埠號等)進行定製,如基於P4進行網路資料平面程式設計,而不需要僅按照傳統軟體定義網路中指定的屬性資訊進行網路流管控,加強網路管理的縱深與融合程度,從而透過全棧式的方式提供開放、靈活、可定製的網路流管理服務。

4) 控制層

控制層集成了面向各層的管理元件,包括容器編排管理模組、服務網格控制器、軟體定義網路控制器和虛擬網路功能編排管理模組MANO。透過控制層與服務層的剝離,實現全棧式便捷靈活的邊緣應用編排管理。容器編排管理模組能夠根據應用需求、訪問需求、物理資源動態變化,基於設定的規則實現容器全生命週期的管理,包括服務註冊、部署、擴容、銷燬等。Kubernetes主節點元件可用於實現這一功能。與之相配合的是服務網格管理器(如Istio Controller),透過管理各個服務對應邊車中 的網路流,實現面向服務的負載均衡、安全監測、 熔斷等執行時操作。軟體定義控制器透過南向介面(如Openflow)向軟體定義交換機注入流表項,管控資料流在網路層中的行為。服務網格控制器與軟體定義控制器能夠相互配合,從不同層面對網路流進行管理。前者主要從服務的角度,從邏輯上管控服務間流量;後者是對前者邏輯管控的物理實現。網路功能管理模組與容器管理模組類似,但兩者的管理物件不同,網路功能管理模組針對各個虛擬網路功能的生命週期進行管理。控制層的各個模組透過相互配合,能夠實現算網融合的高效排程,符合當下分散式計算的發展趨勢。

04面向邊緣計算的低開銷微服務部署

與資源相對豐富的雲計算資料中心不同,邊緣計算資源容量匱乏。在應用雲原生技術於邊緣計算時,資源開銷是需要考慮的一個重要方面。微服務部署是實現雲原生應用的重要基礎,高效地部署微服務對雲原生邊緣計算具有重要意義。

雲原生的支撐技術之一——容器也為實現低開銷微服務部署提供了新的最佳化點,儘管邊緣計算中的微服務部署最佳化研究已被廣泛關注

[20-21]

,但現有的研究一般將容器視為輕量級的虛擬機器,往往忽略了其分層屬性。因此,本節將探討如何發掘利用容器的分層屬性實現低開銷的微服務部署最佳化。

4.1 容器分層與問題陳述

容器在實現時不是一個整體,而是按照分層結構組織。如加入某容器基於Ubuntu系統實現,且需要MySQL資料庫的支援。可以理解為,容器的底層是一個Ubuntu 映象,其上疊加了一個MySQL層,再在上面疊加所需的操作,這樣便能組成一個完整的服務功能。顯然,當在同一臺物理機上部署多個容器時,如果容器間進行層共享,就能夠有效降低開銷。一方面,在映象拉取時,層共享使得不需要拉取冗餘的層,不僅降低了網路開銷還有利於服務的快速啟動;另一方面,邊緣伺服器也不需要冗餘儲存容器的層,能夠有效降低儲存資源開銷。

邊緣計算環境中的分散式伺服器的資源有限, 同時需要部署的容器具有不同的計算與儲存資源需求,如何綜合考慮容器的分層特性,實現邊緣計算環境中的低開銷容器部署,對雲原生邊緣計算具有重要意義。首先構建分層敏感的低開銷容器部署最佳化理論模型,為便於讀者理解,總結了模型中涉及的數學符號與其定義,數學符號與定義如表1所示。

雲原生邊緣計算:探索與展望

4.2 層共享敏感的低開銷容器部署最佳化

雲原生邊緣計算:探索與展望

雲原生邊緣計算:探索與展望

雲原生邊緣計算:探索與展望

雲原生邊緣計算:探索與展望

雲原生邊緣計算:探索與展望

雲原生邊緣計算:探索與展望

雲原生邊緣計算:探索與展望

圖4 主要考慮容器數量的增多對部署開銷(以儲存佔用為衡量)的影響。從圖4中可以看出,隨著容器數量的增加,3個演算法所需要的總儲存空間也逐漸增加。對比3個演算法可以看出,考慮層共享的部署方案在儲存資源佔用上均優於無層共享的方案。此外,本文所提的鬆弛演算法可以取得逼近最優解的結果。

如4 圖所示,當容器數量較少時,能夠共享的層數量有限導致規劃空間有限,鬆弛演算法幾乎可以得到與最優解相同的結果。隨著容器數量的增加,佔用的空間也越來越多,因此總消耗呈上升趨勢。但是由圖4可以看出,採用層共享方法儲存的方式可以使開銷得到明顯降低,容器數量越多,優勢越明顯。這是因為,隨著容器數量的增加,可共享的層越來越多,層共享的優勢也越來越明顯。

圖5展示了伺服器資源的提升對部署開銷的影響,將資源大小隨倍數增加,隨著儲存空間、計算資源和通訊資源的增加,同一個伺服器上可部署的容器數量也會逐漸增加,越來越多的容器可以被部署在同一個伺服器上,潛在地能夠共享更多的層,從而降低容器的總部署開銷,而無層共享的方案則一直需要相同的部署開銷。實驗結果證明了層共享在部署開銷上的優勢,當儲存空間、計算資源和通訊資源增加到一定程度時,所有容器可以部署在一個或少數幾個伺服器上,此時鬆弛演算法和最優解取得了相同結果。

05展望與挑戰

儘管雲原生對推動邊緣計算發展具有極大的 潛力,工業界也相繼推出了相關解決方案,但仍處於該方向研究的初始階段。由於邊緣計算環境與雲計算資料中心的本質區別,雲原生邊緣計算還存在諸多挑戰。本節將展望並分析可能存在的挑戰。

1) 廣分佈高異構資源管理

邊緣計算資源分散在不同地理分佈的地方,如使用者終端裝置、通訊基站、智慧路由器、邊緣伺服器等。而云計算中的資源都是集中式的管理,因此雲計算的資源管理方式和框架(如OpenStack)不適用於管理邊緣計算分散的資源,亟需發展新的適應廣分佈高異構邊緣資源管理的解決方案。目前,關於邊緣計算資源的管控研究大多集中在演算法層面,容易忽略在具體部署實踐中的某些細節。

此外,CPU架構差異(如X86與ARM)、硬體加速器並存(如FPGA、GPU等)、有線與無線共在等特性, 均對邊緣資源管理帶來了極大的挑戰。儘管雲原生使應用開發執行維護人員能夠遠離這些細節,但對基礎設施管理人員提出了要求,需要其能夠設計出上層應用透明,但又對上層應用特徵敏感(如本文所述容器的分層結構)的高效解決方案。

2) 分散式服務狀態管理

雲原生計算中的微服務或者函式功能自身均 不保留狀態,但實際上並非所有服務或函式都沒有狀態,狀態管理因此成為雲原生必須討論的一個問題。在雲原生邊緣計算中,這一問題變得更突出,主要由於前述邊緣計算平臺環境自身的特徵所致。此外,邊緣計算中的服務請求可能具有高度移動性,以及由此導致的時空異構性。這都對雲原生邊緣計算的狀態管理帶來了新的挑戰。

顯然,集中式的狀態管理不適用於雲原生邊緣計算,亟需發展分散式服務狀態管理方法。由於邊緣計算環境的高時空異構動態性,服務會高速動態部署、銷燬、擴容, 相應的分散式服務狀態的儲存位置(一份或多份複製)、儲存方式(如記憶體或硬碟)、同步方式(若存 在多份狀態複製)、更新方式(增量更新或全覆蓋 更新)等均需要與服務的生命週期管理耦合匹配,實現高效的服務狀態管控。

3) 邊緣智慧的應用

邊緣智慧隨著邊緣計算的發展逐漸成為一個熱點話題。儘管邊緣智慧主要指在邊緣計算平臺上部署的各類人工智慧應用,本文認為邊緣智慧的一個重要應用物件就是邊緣計算平臺自身。雲計算資料中心需要自動化、智慧化執行維護方案,廣分佈高異構且資源供需動態性高的邊緣計算平臺更需要智慧化執行維護。

然而,相較於雲資料中心,基於邊緣智慧的邊緣平臺執行維護面臨著環境複雜和算力有限兩方面挑戰。如海量的微服務需要在拓撲非規則、資源高異構的邊緣平臺上進行部署、擴容、縮容等操作,同時伴隨著服務請求的高度時空動態性,需觀測的資料不僅數量大而且維度大,並且對資料處理的時效性要求高。這都與算力有限的邊緣伺服器構成矛盾,透過雲邊端融合構建分散式的邊緣智慧環境,透過智慧體協作共同完成雲原生邊緣計算執行時的智慧管控是潛在的發展途徑。強化學習(包括深度強化學習)、聯邦學習、遷移學習等都是潛在的支撐技術。

4) 雲原生邊緣應用安全與隱私

雲原生的核心支撐技術是容器。相較於虛擬機器,容器的不足之處是其低隔離性。低隔離性導致部署在同一物理機或虛擬機器上的不同容器不僅存在資源競爭,並且存在安全與隱私風險。然而,雲原生難於擯棄低隔離性的容器在於其輕便性,兩者很難兼得。因此,在可能有多邊緣計算設施提供商以及多邊緣服務提供商共存的雲原生邊緣計算環境中,保障邊緣應用的安全與隱私勢在必行。

本文認為,利用可信執行環境(TEE,trust execution environment)是潛在的解決方案之一。當前各個主流的CPU廠商均推出了自己的TEE 產品,如Intel公司的SGX、ARM公司的TrustZone等。然而,TEE為了保障業務的安全保密執行,也引來了諸多 必須考慮的因素。如SGX的安全記憶體空間有限,而TrustZone 的CPU要求獨佔。容器(包括安全容器與非安全容器)的編排排程,如何與TEE的特徵相適應,是亟待研究的一個方向。

06結 束 語

雲原生技術在雲計算中的應用為邊緣計算的發展指明瞭新的潛在發展方向。本文首先簡要介紹了雲原生的相關概念與關鍵技術。在此基礎上,針對邊緣計算的場景特徵,融入軟體定義網路與網路功能虛擬化,提出了全棧式的雲原生邊緣計算架構。該架構透過控制層面與服務層面的抽象剝離,能夠實現高效的算網協同邊緣資源管理與應用執行維護。

進一步地,針對雲原生的技術特徵,本文研究了容器分層特性敏感的低開銷容器部署最佳化方案。透過該例項研究表明,雲原生邊緣計算中的資源管控必須考慮雲原生自身所引入的新特徵。最後,展望了雲原生邊緣計算發展所面臨的新挑戰。總之,雲原生非常契合邊緣計算,儘管它是一個新興的概念與技術,隨著研究的不斷深入,未來一定能夠得到巨大的發展,期待這個領域內部的技術突破。

參考文獻

參考文獻:

[1] XU J, CHEN L X, ZHOU P。 Joint service caching and task offloading for mobile edge computing in dense networks[C]//IEEE INFOCOM 2018 - IEEE Conference on Computer Communications。 IEEE, 2018: 207-215。

[2] CHEN X, JIAO L, LI W Z, et al。 Efficient multi-user computation offloading for mobile-edge cloud computing[J]。 IEEE/ACM Transactions on Networking, 2016, 24(5): 2795-2808。

[3] DAI Y Y, XU D, MAHARJAN S, et al。 Joint computation offloading and user association in multi-task mobile edge computing[J]。 IEEE Transactions on Vehicular Technology, 2018, 67(12): 12313-12325。

[4] ZHOU Y Q, TIAN L, LIU L, et al。 Fog computing enabled future mobile communication networks: a convergence of communication and computing[J]。 IEEE Communications Magazine, 2019, 57(5): 20-27。

[5] QI Y L, TIAN L, ZHOU Y Q, et al。 Mobile edge computing-assisted admission control in vehicular networks: the convergence of communication and computation[J]。 IEEE Vehicular Technology Magazine, 2019, 14(1): 37-44。

[6] ZHOU Y Q, LIU L, WANG L, et al。 Service-aware 6G: an intelligent and open network based on the convergence of communication, computing and caching[J]。 Digital Communications and Networks, 2020, 6(3): 253-260。

[7] KRL M, MASTORAKIS S, ORAN D, et al。 Compute first networking: distributed computing meets ICN[C]//The 6th ACM Conference on Information-Centric Networking。 ACM, 2019: 67-77。

[8] 劉澤寧, 李凱, 吳連濤, 等。 多層次算力網路中代價感知任務排程演算法[J]。 計算機研究與發展, 2020, 57(9): 1810-1822。

LIU Z N, LI K, WU L T, et al。 CATS: cost aware task scheduling in multi-tier computing networks[J]。 Journal of Computer Research and Development, 2020, 57(9): 1810-1822。

[9] PORAMBAGE P, OKWUIBE J, LIYANAGE M, et al。 Survey on multi-access edge computing for Internet of Things realization[J]。 IEEE Communications Surveys & Tutorials, 2018, 20(4): 2961-2991。

[10] TALEB T, SAMDANIS K, MADA B, et al。 On multi-access edge computing: a survey of the emerging 5G network edge cloud architecture and orchestration[J]。 IEEE Communications Surveys & Tutorials, 2017, 19(3): 1657-1681。

[11] LEBRE A, PASTOR J, SIMONET A, et al。 Revising OpenStack to operate fog/edge computing infrastructures[C]//2017 IEEE International Conference on Cloud Engineering (IC2E)。 IEEE, 2017: 138-148。

[12] NIU Y P, LIU F M, LI Z P。 Load balancing across microservices[C]//IEEE INFOCOM 2018 - IEEE Conference on Computer Communications。 IEEE, 2018: 198-206。

[13] 鄔江興。 新型網路技術發展思考[J]。 中國科學: 資訊科學, 2018, 48(8): 1102-1111。

WU J X。 Thoughts of the development of novel network technology[J]。 SCIENTIA SINICA Informationis, 2018, 48(8): 1102-1111。

[14] 朱建軍, 方琰崴。 面向服務的5G雲原生核心網及關鍵技術研究[J]。 數字通訊世界, 2018(2): 111。

ZHU J J, FANG Y W。 Research on service oriented 5g cloud native core network and its key technologies[J]。 Digital Communication World, 2018(2): 111。

[15] 王全。 雲原生Cloud Native核心網方案及關鍵技術[J]。 中國新通訊, 2018, 20(9): 61-62。

WANG Q。 Cloud native core network scheme and key technologies[J]。 China New Telecommunications, 2018, 20(9): 61-62。

[16] 胡聰叢。 無伺服器計算的現狀以及所面臨的挑戰[J]。網路安全技術與應用,2019(12):84-85。

HU C C。 The current situation and challenges of serverless computing[J]。 Network Security Technology & Application, 2019(12): 84-85。

[17] HUNG Y H, WANG C Y。 Fog micro service market: Promoting fog computing using free market mechanism[C]//2018 IEEE Wireless Communications and Networking Conference (WCNC)。 IEEE, 2018: 1-6。

[18] YU R, KILARI V T, XUE G, et al。 Load balancing for interdependent IoT microservices[C]//IEEE Conference on Computer Communications。 IEEE, 2019。

[19] LI W B, LEMIEUX Y, GAO J, et al。 Service mesh: challenges, state of the art, and future research opportunities[C]//2019 IEEE International Conference on Service-Oriented System Engineering (SOSE)。 IEEE, 2019: 122-1225。

[20] VILLARI M, CELESTI A, TRICOMI G, et al。 Deployment orchestration of microservices with geographical constraints for Edge computing[C]//2017 IEEE Symposium on Computers and Communications (ISCC)。 IEEE, 2017: 633-638。

[21] Wang Y, Zhao C, Yang S, et al。 MPCSM: Microservice Placement for Edge-Cloud Collaborative Smart Manufacturing[J]。 IEEE Transactions on Industrial Informatics, 2020。

作者簡介

曾德澤

(1984),男,中國地質大學(武漢)教授、博士生導師,主要研究方向為邊緣計算、未來網路技術、物聯網等。

陳律昊

(1996),男,中國地質大學(武漢)碩士生,主要研究方向為邊緣計算、微服務部署等。

顧琳

(1985),女,華中科技大學副教授,主要研究方向為邊緣計算、未來網路技術等。

李躍鵬

(1994),男,中國地質大學(武漢)博士生,主要研究方向為邊緣計算、任務排程、可信執行環境等。

關於物聯網學報

《物聯網學報》是由工業和資訊化部主管,人民郵電出版社主辦的中文學術期刊,辦刊宗旨是“服務科學發展,傳播科學知識,促進科技創新,培養科技人才”。

Tags:邊緣計算容器原生服務