面向算力網(wǎng)絡(luò)的邊緣資源調(diào)度解決方案研究

李銘軒 ，曹暢 ，唐雄燕，何濤，李建飛，劉秋妍

1.中國聯(lián)通網(wǎng)絡(luò)技術(shù)研究院，未來網(wǎng)絡(luò)研究部，北京 100048

2.中國聯(lián)通網(wǎng)絡(luò)技術(shù)研究院，無線技術(shù)研究部，北京 100048

引 言

隨著云計(jì)算技術(shù)的發(fā)展與企業(yè)上云的加速推進(jìn)，基于云化架構(gòu)構(gòu)建企業(yè)基礎(chǔ)設(shè)施平臺(tái)已經(jīng)成為業(yè)務(wù)普遍采用的方式。預(yù)計(jì)到2025年，85%的企業(yè)應(yīng)用將會(huì)承載在云上[1]。同時(shí)電信運(yùn)營商一直十分重視云計(jì)算市場和技術(shù)的發(fā)展，其內(nèi)部IT 系統(tǒng)已經(jīng)基本完成云化改造，正在推動(dòng)其核心業(yè)務(wù)云化改造，并且紛紛成立專業(yè)云服務(wù)公司，開拓企業(yè)市場[2]。隨著國家大力提倡發(fā)展新基建，云計(jì)算作為基礎(chǔ)設(shè)施建設(shè)的重點(diǎn)領(lǐng)域?qū)?huì)得到快速的發(fā)展。

現(xiàn)有的云計(jì)算發(fā)展方向包括兩個(gè)方面：一方面沿著傳統(tǒng)的技術(shù)路線發(fā)展，采用資源集約化的方式著重建設(shè)大規(guī)模和超大規(guī)模數(shù)據(jù)中心，并且由數(shù)據(jù)中心統(tǒng)一提供IT 資源；另一方面的云計(jì)算發(fā)展路線則是著重研究面向異構(gòu)云計(jì)算資源進(jìn)行協(xié)同和納管，其中多云管理目前是這種云計(jì)算技術(shù)發(fā)展方向的代表。而隨著5G 技術(shù)的發(fā)展，邊緣計(jì)算成為了信息技術(shù)領(lǐng)域和通信技術(shù)領(lǐng)域相互結(jié)合的熱點(diǎn)。和傳統(tǒng)的云計(jì)算發(fā)展路線不同，邊緣計(jì)算主要研究如何更好地將外圍或者邊緣資源有效的進(jìn)行管理，這就為邊緣計(jì)算的研究提出了挑戰(zhàn)。一方面，因?yàn)檫吘壻Y源更靠近用戶側(cè)，要求更低的用戶訪問時(shí)延；另一方面，邊緣計(jì)算設(shè)備數(shù)量眾多，而且存在計(jì)算架構(gòu)差異性等問題，如何實(shí)現(xiàn)對(duì)海量的異構(gòu)邊緣計(jì)算資源的統(tǒng)一管理等也是一種挑戰(zhàn)。另外，由于邊緣計(jì)算節(jié)點(diǎn)分布比較廣泛，計(jì)算節(jié)點(diǎn)之間的協(xié)同和資源的調(diào)度相比于傳統(tǒng)的云計(jì)算對(duì)于網(wǎng)絡(luò)的要求更高，因此邊緣計(jì)算的研究除了傳統(tǒng)的計(jì)算、存儲(chǔ)等虛擬化技術(shù)的研究外，需要更加關(guān)注如何實(shí)現(xiàn)網(wǎng)絡(luò)和邊緣計(jì)算的協(xié)同，從傳統(tǒng)的云網(wǎng)融合向算網(wǎng)融合的方向發(fā)展。

本文主要研究了基于算力網(wǎng)絡(luò)如何實(shí)現(xiàn)對(duì)于邊緣嵌入式計(jì)算資源，諸如ARM、GPU 等多種嵌入式設(shè)備進(jìn)行資源納管，從而能夠解決算力網(wǎng)絡(luò)下的異構(gòu)計(jì)算資源協(xié)同管理問題。

1 算力網(wǎng)絡(luò)

算力網(wǎng)絡(luò)從傳統(tǒng)云網(wǎng)融合的角度出發(fā)，結(jié)合邊緣計(jì)算、網(wǎng)絡(luò)云化以及智能控制的優(yōu)勢，通過網(wǎng)絡(luò)連接實(shí)現(xiàn)更加廣泛的算力資源的納管和動(dòng)態(tài)調(diào)度。但是，區(qū)別于傳統(tǒng)的云計(jì)算資源的納管采用集中式的資源管理或者集約化的資源提供，在算力網(wǎng)絡(luò)的資源納管中更多考慮了網(wǎng)絡(luò)延時(shí)、網(wǎng)絡(luò)損耗對(duì)于資源調(diào)度方面的影響。因此網(wǎng)絡(luò)的核心價(jià)值是提高效率，算力網(wǎng)絡(luò)的出現(xiàn)正是為了提高端、邊、云三級(jí)計(jì)算的協(xié)同工作效率。算力網(wǎng)絡(luò)整體技術(shù)架構(gòu)如圖1所示。

圖1 算力網(wǎng)絡(luò)技術(shù)架構(gòu)Fig.1 Technology architecture on computing power network

依據(jù)上述算力網(wǎng)絡(luò)架構(gòu)，通過計(jì)算和網(wǎng)絡(luò)的聯(lián)動(dòng)將云、邊、端設(shè)備協(xié)同統(tǒng)一起來。其中中心云采用傳統(tǒng)的云計(jì)算實(shí)現(xiàn)集中式的資源統(tǒng)一管理，在中心云中主要面向大規(guī)?；蛘叱笠?guī)模的數(shù)據(jù)處理，以電信運(yùn)營商為例，中心云主要承載面向全國的業(yè)務(wù)平臺(tái)運(yùn)營和數(shù)據(jù)處理[2]。在邊緣云由于接入的邊緣數(shù)據(jù)中心眾多，而且分布比較廣泛，基本上每一個(gè)邊緣數(shù)據(jù)中心通常會(huì)采用相對(duì)獨(dú)立的輕量化容器集群來實(shí)現(xiàn)，而在特殊行業(yè)或者指定場景下，行業(yè)用戶擁有自己獨(dú)立的數(shù)據(jù)中心或者業(yè)務(wù)上要求數(shù)據(jù)保密等場景下，也要求在用戶環(huán)境下形成一個(gè)相對(duì)比較獨(dú)立的云資源池[3]，同時(shí)在邊緣云的統(tǒng)一管理中，需要將此部分單獨(dú)作為獨(dú)立的邊緣云進(jìn)行管理，同時(shí)在算力的分配或者應(yīng)用的部署方面需要指定部署到用戶的邊緣云內(nèi)，因此邊緣云多數(shù)采用Kubernetes多集群的方式來實(shí)現(xiàn)多個(gè)邊緣計(jì)算集群的協(xié)同管理。在算力網(wǎng)絡(luò)設(shè)備端側(cè)，結(jié)合現(xiàn)有工業(yè)互聯(lián)網(wǎng)以及智慧城市等場景，往往涉及海量的前端嵌入式邊緣設(shè)備，而且采用的計(jì)算架構(gòu)有ARM、DSP、FPGA、SOC 等，負(fù)責(zé)用戶的數(shù)據(jù)采集、用戶側(cè)的業(yè)務(wù)訪問入口和交互等，因此通過算力網(wǎng)絡(luò)將整個(gè)云、邊、端的計(jì)算資源協(xié)同起來，采用分級(jí)、多集群的方式進(jìn)行統(tǒng)一管理。目前在中心云主要采用OpenStack等傳統(tǒng)的IaaS 進(jìn)行承載[4]，而在邊緣或者遠(yuǎn)端設(shè)備上的計(jì)算資源通過輕量級(jí)的云原生Kubernetes 等i-PaaS 和A-Paas 進(jìn)行計(jì)算資源的管理和應(yīng)用能力的管理等。

2 輕量級(jí)云原生架構(gòu)

依據(jù)上述算力網(wǎng)絡(luò)整體架構(gòu)，在電信運(yùn)營商的數(shù)據(jù)中心分級(jí)部署方案中，邊緣數(shù)據(jù)中心或者邊緣機(jī)房主要突出計(jì)算靈活、輕量化等特點(diǎn)，面向用戶提供低延時(shí)的網(wǎng)絡(luò)接入和應(yīng)用訪問，因此現(xiàn)有的邊緣資源的算力調(diào)度方案主要采用基于云原生方式來實(shí)現(xiàn)的，面向用戶提供業(yè)務(wù)平臺(tái)的快速部署、業(yè)務(wù)訪問，而其中資源調(diào)度和管理平臺(tái)是以Kubernetes為主的容器云來實(shí)現(xiàn)資源調(diào)度編排和統(tǒng)一管理。依據(jù)參考文獻(xiàn)[5]所描述，Kubernetes 主要采用主從模式來實(shí)現(xiàn)計(jì)算節(jié)點(diǎn)的統(tǒng)一管理，其總體技術(shù)架構(gòu)如圖2 所示[5]。

圖2 Kubernetes 技術(shù)架構(gòu)Fig.2 Technology architecture on Kubernetes

結(jié)合Kubernetes 技術(shù)架構(gòu)主要采用主從模式，Master 節(jié)點(diǎn)主要負(fù)責(zé)資源的調(diào)度和鍵值數(shù)據(jù)庫的存儲(chǔ)，同時(shí)實(shí)現(xiàn)POD 的生命周期管理，同時(shí)Node 節(jié)點(diǎn)主要作為計(jì)算節(jié)點(diǎn)，實(shí)現(xiàn)本地Pod 的部署運(yùn)行和本地相關(guān)計(jì)算、存儲(chǔ)和網(wǎng)絡(luò)資源的納管。因此Kubernetes在開源之初，就定位為 i-PaaS 功能，既具備上層PaaS 平臺(tái)的能力，同時(shí)又對(duì)底層IaaS 資源具備資源納管的能力。隨著近年來Kuberentes技術(shù)的飛速發(fā)展，目前Kuberentes 已經(jīng)發(fā)展到了1.17 版本，不僅僅可以納管通用CPU 等通用計(jì)算資源，同時(shí)也支持對(duì)于GPU、ARM 等專用計(jì)算資源的管理。

另一方面，由于通用型的嵌入式設(shè)備自身的計(jì)算、內(nèi)存以及存儲(chǔ)等方面的資源有限，從而導(dǎo)致Kubernetes 在進(jìn)行部署時(shí)受到限制?，F(xiàn)有的解決方案往往通過修改嵌入式設(shè)備的系統(tǒng)配置，諸如擴(kuò)展SWAP 交換空間等方式以保證Kubernetes 能夠順利的安裝[6]，參考文獻(xiàn)[6]正是按照此種方式實(shí)現(xiàn)的。但是在實(shí)際設(shè)備運(yùn)行過程中還是存在容器運(yùn)行受限、集群本身數(shù)據(jù)庫和相關(guān)組件運(yùn)行占用較多資源等問題。針對(duì)這些問題在業(yè)界也越來越引起廣泛的關(guān)注，目前在云原生開源社區(qū)最新開源項(xiàng)目K3S 針對(duì)原有Kubernetes 進(jìn)行功能裁剪和優(yōu)化，使其成為更加輕量化的容器云編排調(diào)度平臺(tái)，能夠更好的應(yīng)用于面向邊緣計(jì)算、物聯(lián)網(wǎng)等場景下的多種嵌入式設(shè)備的部署和容器編排管理，因此項(xiàng)目一經(jīng)發(fā)布在社區(qū)獲得廣泛關(guān)注，其技術(shù)架構(gòu)如圖3 所示。

和Kubernetes 技術(shù)架構(gòu)相比，K3S 的技術(shù)架構(gòu)同樣是采用C/S 架構(gòu)，并且在Server 主要通過KubeAPI 來實(shí)現(xiàn)和Kubernetes 中的API Server 相同的功能，通過KubeAPI 提供集中的連接，并且通過Controller Mananger 和Scheduler 來實(shí)現(xiàn)節(jié)點(diǎn)管理和資源調(diào)度管理等，這樣外部系統(tǒng)在訪問K3S 集群時(shí)，可以采用標(biāo)準(zhǔn)的Kubernetes 的接口進(jìn)行訪問，而不需要再單獨(dú)開發(fā)一套獨(dú)立的訪問接口。不同點(diǎn)在于原有的Kubernetes 采用etcd 鍵值型數(shù)據(jù)庫來實(shí)現(xiàn)數(shù)據(jù)管理，而在K3S 中為了滿足輕量化的需求，改用SQLite 實(shí)現(xiàn)數(shù)據(jù)庫管理。同時(shí)在底層容器引擎方面采用Containerd 來實(shí)現(xiàn)POD 管理。

圖3 K3S 技術(shù)架構(gòu)Fig.3 Technology architecture on K3S

在系統(tǒng)集成方面，由于整個(gè)云原生平臺(tái)之間都是通過API 接口實(shí)現(xiàn)相互之間的訪問和調(diào)用，而K3S 平臺(tái)主要是由KubeAPI 提供外部訪問接口，同時(shí)該接口是經(jīng)過CNCF 認(rèn)證的標(biāo)準(zhǔn)Kubernetes 接口，因此K3S 接口和標(biāo)準(zhǔn)的Kubernetes 的接口是一致的，可以實(shí)現(xiàn)無縫對(duì)接?；贙3S 技術(shù)架構(gòu)設(shè)計(jì)的考慮一方面可以保證K3S 對(duì)外提供標(biāo)準(zhǔn)的Kubernetes 平臺(tái)接口；另一方面，經(jīng)過架構(gòu)的精簡和優(yōu)化，使得K3S 本身的架構(gòu)更加輕量化，整個(gè)的可執(zhí)行性文件可以精簡到幾十兆，能夠更加適用于在嵌入式系統(tǒng)等有限計(jì)算平臺(tái)上進(jìn)行部署。

3 邊緣資源調(diào)度方案

根據(jù)參考文獻(xiàn)[7]所描述的算力網(wǎng)絡(luò)的四個(gè)特征要求，包括：資源抽象、業(yè)務(wù)保證、統(tǒng)一管控和彈性調(diào)度等方面，其中彈性調(diào)度能夠?qū)崟r(shí)檢測業(yè)務(wù)流量，動(dòng)態(tài)調(diào)整算力資源，完成各類任務(wù)高效處理和整合輸出，并在滿足業(yè)務(wù)需求的前提下實(shí)現(xiàn)資源的彈性伸縮，優(yōu)化算力分配[7]。在算力網(wǎng)絡(luò)資源調(diào)度方面，一方面采用輕量級(jí)的容器調(diào)度平臺(tái)適配于開放式嵌入式邊緣計(jì)算集群；另一方面，實(shí)現(xiàn)了統(tǒng)一的多集群的邊緣計(jì)算集群的統(tǒng)一管控和動(dòng)態(tài)擴(kuò)縮容的資源彈性調(diào)度。結(jié)合現(xiàn)實(shí)情況，由于現(xiàn)有在邊緣側(cè)的設(shè)備資源中存在大量的嵌入式等工控設(shè)備等，因自身的計(jì)算資源和存儲(chǔ)資源有限，傳統(tǒng)的Kubernetes 云原生架構(gòu)無法承載，因此本文在面向算力網(wǎng)絡(luò)的邊緣資源調(diào)度方案設(shè)計(jì)過程中，考慮采用“Kubernetes+K3S”的分級(jí)云原生容器資源調(diào)度方案，前端嵌入式設(shè)備基于K3S 實(shí)現(xiàn)資源管理，基于Kubernetes 來實(shí)現(xiàn)云原生多集群的統(tǒng)一管理。

3.1 邊緣系統(tǒng)整體架構(gòu)

在面向算力網(wǎng)絡(luò)Kubernetes 多集群計(jì)算資源管理方面，本文采用基于“Kubernetes+K3S”兩級(jí)聯(lián)動(dòng)的架構(gòu)來實(shí)現(xiàn)統(tǒng)一的邊緣側(cè)資源調(diào)度管理，即邊緣計(jì)算節(jié)點(diǎn)側(cè)采用傳統(tǒng)Kubernetes 云原生實(shí)現(xiàn)邊緣計(jì)算節(jié)點(diǎn)側(cè)的資源納管，同時(shí)負(fù)責(zé)底層嵌入式終端集群的注冊(cè)和管理等統(tǒng)一多集群調(diào)度管理，而前端嵌入式終端集群則采用更加輕量級(jí)的K3S 云原生平臺(tái)實(shí)現(xiàn)資源管理，其總體的技術(shù)架構(gòu)如圖4 所示。

圖4 邊緣系統(tǒng)技術(shù)架構(gòu)Fig.4 Technology architecture on edge system

依據(jù)上述系統(tǒng)技術(shù)架構(gòu)，在面向整個(gè)邊緣系統(tǒng)的資源調(diào)度方面主要是基于云原生容器化的方式來實(shí)現(xiàn)。以電信運(yùn)營商為例，現(xiàn)有邊緣側(cè)的基礎(chǔ)設(shè)施部署情況，邊緣云主要分布在省分地市級(jí)邊緣機(jī)房或者用戶的數(shù)據(jù)中心內(nèi)，主要采用通用型服務(wù)器作為計(jì)算節(jié)點(diǎn)，硬件性能相對(duì)較高，同時(shí)可以支持GPU、FPGA 等多種加速硬件資源，因此集中部署云原生的Kubernetes 容器集群，甚至有些邊緣云部署輕量級(jí)的OpenStack 云計(jì)算集群，比如目前著名的邊緣計(jì)算解決方案StarlingX，而前端設(shè)備則主要連接海量的嵌入式設(shè)備，負(fù)責(zé)數(shù)據(jù)采集、工業(yè)控制以及用戶交互訪問等。目前市場上的嵌入式設(shè)備主要基于“MCU+協(xié)處理器”的SOC 架構(gòu)來實(shí)現(xiàn)，其中MCU 目前普遍采用ARM 架構(gòu)的處理器實(shí)現(xiàn)設(shè)備的管理和連接，而協(xié)處理器則面向不同的數(shù)據(jù)處理類型采用不同的專用芯片，比如GPU 主要面向二維數(shù)據(jù)的圖像處理和視頻處理，NPU 主要面向張量數(shù)據(jù)的處理等。本文基于輕量級(jí)的K3S 實(shí)現(xiàn)容器化的嵌入式設(shè)備資源調(diào)度，應(yīng)用程序?qū)⒏鶕?jù)策略以POD 的形式調(diào)度到指定的嵌入式設(shè)備上運(yùn)行，同時(shí)前端接入的傳感器設(shè)備或者工控設(shè)備等通過MQTT、HTTP和GRPC 等通信協(xié)議將采集到的數(shù)據(jù)上傳到嵌入式設(shè)備上進(jìn)行處理，或者將嵌入式設(shè)備發(fā)送的指令傳遞到前端設(shè)備上執(zhí)行[8]。

3.2 基于ARM 的容器部署

本文主要采用K3S 的ARM 部署方式，根據(jù)參考文獻(xiàn)[9]所描述的部署需求，目前的K3S 版本支持硬件最低要求僅需要1 個(gè)CPU、512M 內(nèi)存，同時(shí)面向X86_64、Arm64 和Armv7 等平臺(tái)發(fā)布，因此基本上涵蓋目前市場上絕大部分ARM 平臺(tái)架構(gòu)[9]，另外K3S 包含了輕量級(jí)的容器引擎Containerd，并不需要額外安裝Docker 引擎，在底層容器引擎方面K3S 可以默認(rèn)采用Containerd 的容器調(diào)度方式，但是也支持通過Docker 方式來實(shí)現(xiàn)容器調(diào)度。在整個(gè)嵌入式設(shè)備的容器部署和調(diào)度方式上，如圖5 所示。

圖5 邊緣設(shè)備容器部署和調(diào)用方式Fig.5 Edge device container deployment, invocation method

依據(jù)容器化部署方式，結(jié)合具體的應(yīng)用場景需要，在部署K3S 的Agent 節(jié)點(diǎn)時(shí)，可以選擇K3S 默認(rèn)的Containerd 作為底層的容器調(diào)度引擎，也可以選擇Docker Engine 作為其容器調(diào)度引擎，但是需要在部署K3S Agent 之前就已經(jīng)成功安裝了Docker Engine，目前Docker Engine 官方也提供面向諸如ARMv7 架構(gòu)的版本。根據(jù)官網(wǎng)安裝部署文檔所描述的具體操作，只需要在安裝部署K3S Agent 時(shí)通過參數(shù)INSTALL_K3S_EXEC=”docker”傳遞給K3S系統(tǒng)，以表明在后續(xù)的容器調(diào)度過程中使用Docker Engine 作為容器調(diào)度引擎。但是需要說明的是，由于K3S 架構(gòu)采用C/S 主從方式，在Agent 節(jié)點(diǎn)的部署過程中可以選擇容器引擎，而在Server 節(jié)點(diǎn)上只能采用Containerd 作為其唯一的容器調(diào)度引擎。因?yàn)樵谡麄€(gè)K3S 的POD 運(yùn)行管理過程中，K3S Agent是作為唯一的POD 運(yùn)行和調(diào)度的載體，而Server 只是負(fù)責(zé)整個(gè)K3S 集群的運(yùn)行管理，因此不需要額外地執(zhí)行相關(guān)的容器運(yùn)行等，通過這種方式可以大大提高K3S Server 的輕量化，也可以實(shí)現(xiàn)Server 和Agent 可在同一個(gè)節(jié)點(diǎn)上進(jìn)行部署。另外，在嵌入式集群中具有控制節(jié)點(diǎn)，相比于其他MEC 方案諸如Kubeedge 等，集群具有自主可控的資源調(diào)度能力，這樣更適合未來基于神經(jīng)網(wǎng)絡(luò)的算力網(wǎng)絡(luò)智能化發(fā)展。

3.3 基于專用芯片的容器部署

面向?qū)Ｓ眯酒倪吘壡度胧皆O(shè)備一般在特定場景下對(duì)于數(shù)據(jù)處理有特殊要求，在芯片的架構(gòu)設(shè)計(jì)上主要采用“MCU+專用芯片”的SOC 方式進(jìn)行構(gòu)建，通常采用ARM 作為MCU（主控單元），具體負(fù)責(zé)整個(gè)設(shè)備的系統(tǒng)管理、外部通信以及訪問，而專用芯片則包括諸如GPU、NPU 以及FPGA 等，專門負(fù)責(zé)數(shù)據(jù)的處理和相關(guān)算法的硬加速處理等功能，而在MCU 和專用芯片之間往往通過專用的數(shù)據(jù)通道進(jìn)行數(shù)據(jù)傳輸，比如HDI、HCI、SPI 等，各廠家設(shè)計(jì)的芯片不同，可能采用的數(shù)據(jù)傳輸協(xié)議也各有不同，而對(duì)外的數(shù)據(jù)輸入和數(shù)據(jù)輸出則主要由MCU 負(fù)責(zé)。由于專用芯片在某些特定場景下對(duì)于數(shù)據(jù)的處理具有較高的處理能力，因此和通用性處理器相比，專用芯片在算法訓(xùn)練、推理和硬件編解碼等方面具有非常明顯的優(yōu)勢，因此在邊緣計(jì)算場景下，開始逐漸采用專用芯片來執(zhí)行算力。目前在容器化部署方案上，各廠商都結(jié)合自家的專用芯片推出了相應(yīng)的解決方案，通常的技術(shù)架構(gòu)則是基于MCU 的嵌入式操作系統(tǒng)提供驅(qū)動(dòng)層或者系統(tǒng)適配層，用于專用芯片的資源訪問接口和資源調(diào)度能力，并通過插件方式實(shí)現(xiàn)Kubernetes 對(duì)于專用芯片資源的調(diào)度和適配。本文以英偉達(dá)的嵌入式開發(fā)板Nvidia Jetson Nano 為例具體闡述面向?qū)Ｓ眯酒腒3S 部署方案和調(diào)度過程，英偉達(dá)在嵌入式系統(tǒng)推出了基于GPU 的驅(qū)動(dòng)層，并且在原生Docker 引擎的基礎(chǔ)上推出了自己的容器編排調(diào)度工具Nvidia-docker，并且該容器引擎和英偉達(dá)的GPU 開放平臺(tái)CUDA 進(jìn)行了完美的適配[10]，因此在容器部署過程中主要基于英偉達(dá)的Nvidiadocker 進(jìn)行容器調(diào)度，并且通過驅(qū)動(dòng)來為POD 分配具體的GPU 資源，其具體的架構(gòu)如圖6 所示。

圖6 GPU 容器部署方式Fig.6 GPU container deployment on GPU

依據(jù)GPU 容器部署方式，在算力資源調(diào)度過程中，可以通過在K3S 集群的配置文件yaml 中創(chuàng)建資源對(duì)象Resource，并且通過配置GPU 的數(shù)據(jù)量來指令K3S 集群為該P(yáng)OD 分配GPU 資源以執(zhí)行相應(yīng)的算力，而該參數(shù)配置會(huì)通過Nvidia-docker 來調(diào)用底層的驅(qū)動(dòng)在創(chuàng)建POD 過程中為其提供指定的GPU數(shù)量。

而在上層的POD 調(diào)度和配置方面，通過上述容器化部署以及POD 資源分配方式，可以在標(biāo)準(zhǔn)的Kubernetes 配置文件yaml 中創(chuàng)建Resource 對(duì)象[11]，并且在該資源對(duì)象中設(shè)置計(jì)算單元數(shù)量，而該資源對(duì)象下的計(jì)算單元類型可以進(jìn)行擴(kuò)展和定義，因此為后續(xù)的其他專用芯片的資源調(diào)度和管理提供了可能。用戶可以在配置文件中為POD 指定不同的專用芯片來運(yùn)行。

3.4 基于標(biāo)簽的算力調(diào)度機(jī)制

在面向算力網(wǎng)絡(luò)的邊緣資源調(diào)度機(jī)制方面，由于考慮需要將整個(gè)邊緣側(cè)和前端嵌入式設(shè)備側(cè)的算力資源統(tǒng)一調(diào)度和納管。在算力應(yīng)用匹配和算力節(jié)點(diǎn)調(diào)度方面，基于Kubernetes 提供的標(biāo)簽以及容器標(biāo)簽來實(shí)現(xiàn)整個(gè)邊緣側(cè)的算力調(diào)度機(jī)制，通過為前端嵌入式設(shè)備在注冊(cè)到K3S 集群時(shí)，為設(shè)備創(chuàng)建節(jié)點(diǎn)標(biāo)簽，同時(shí)在創(chuàng)建POD 時(shí)可以通過節(jié)點(diǎn)標(biāo)簽將POD 部署到指定的邊緣節(jié)點(diǎn)上運(yùn)行，其調(diào)度流程如圖7 所示。

基于標(biāo)簽的算力資源調(diào)度機(jī)制主要是基于Kubernetes 的Scheduler 和Controller manager 來實(shí)現(xiàn)的。首先在創(chuàng)建K3S 集群時(shí)，為算力節(jié)點(diǎn)統(tǒng)一進(jìn)行命令規(guī)則，而算力節(jié)點(diǎn)的標(biāo)簽命名統(tǒng)一由設(shè)備管理模塊進(jìn)行管理，并且維護(hù)整個(gè)集群中設(shè)備節(jié)點(diǎn)的基本信息。在創(chuàng)建容器時(shí)根據(jù)應(yīng)用場景和用戶需求的不同，通過在設(shè)備管理模塊中查詢匹配的計(jì)算節(jié)點(diǎn)，并且在創(chuàng)建容器的配置文件中進(jìn)行指定，從而使得資源調(diào)度平臺(tái)為容器應(yīng)用分配合適的計(jì)算節(jié)點(diǎn)。

4 應(yīng)用場景

目前業(yè)界正在積極探索算力網(wǎng)絡(luò)和工業(yè)互聯(lián)網(wǎng)以及物聯(lián)網(wǎng)等行業(yè)的實(shí)際落地場景，以智能駕駛業(yè)務(wù)場景下的算力網(wǎng)絡(luò)資源調(diào)度為例，車載系統(tǒng)一方面在保證低時(shí)延的數(shù)據(jù)處理需求的情況下，需要將數(shù)據(jù)和控制盡可能的保證在本地進(jìn)行處理，同時(shí)需要通過MEC 等實(shí)現(xiàn)云端資源和策略調(diào)度等協(xié)同智能路燈等信號(hào)的處理和反饋；另一方面，由于車載系統(tǒng)本身的計(jì)算和存儲(chǔ)能力有限，因此需要基于正如本文所述的K3S 等輕量級(jí)的資源調(diào)度系統(tǒng)來實(shí)現(xiàn)車載系統(tǒng)的資源管理和應(yīng)用運(yùn)行。具體如圖8 所示。

圖7 基于標(biāo)簽的算力資源調(diào)度Fig.7 Computing power resource scheduling based on label

圖8 面向智能駕駛的算力網(wǎng)絡(luò)資源調(diào)度Fig.8 Resource scheduling of computing power network for intelligent driving

基于上述智能駕駛應(yīng)用場景下的算力網(wǎng)絡(luò)資源調(diào)度，通過環(huán)境感知來實(shí)現(xiàn)周圍智能設(shè)備的數(shù)據(jù)采集和智能訓(xùn)練以實(shí)現(xiàn)無人駕駛車輛自主識(shí)別障礙物，通過避障規(guī)劃來實(shí)現(xiàn)判斷障礙物后所采取的措施，并且跟蹤障礙物并及時(shí)做出判斷和措施。上述流程強(qiáng)調(diào)智能駕駛車輛自主的學(xué)習(xí)處理能力以及及時(shí)和中心業(yè)務(wù)平臺(tái)的聯(lián)動(dòng)時(shí)延要求，運(yùn)營商目前積極推動(dòng)“5G+MEC”實(shí)現(xiàn)智能駕駛的解決方案以實(shí)現(xiàn)低時(shí)延和資源輕量化調(diào)度，從而拉動(dòng)包括智能駕駛、智能燈桿、智能交通控制等智慧城市公共交通的整體協(xié)同和資源管理。

5 結(jié)論和展望

隨著算力網(wǎng)絡(luò)技術(shù)的發(fā)展，將廣泛的邊緣計(jì)算節(jié)點(diǎn)納入到統(tǒng)一的資源管理，尤其是在算力網(wǎng)絡(luò)中引入嵌入式設(shè)備管理和自主資源調(diào)度機(jī)制，改變了傳統(tǒng)的嵌入式設(shè)備只能被動(dòng)接受服務(wù)器指令和上傳數(shù)據(jù)采集等工作模式，使得嵌入式設(shè)備集群更具自適應(yīng)能力，為后續(xù)AI 算力以及神經(jīng)網(wǎng)路架構(gòu)下的深度學(xué)習(xí)分層在嵌入式設(shè)備集群上的部署和運(yùn)行，以及嵌入式設(shè)備的自主學(xué)習(xí)能力和智能交互提供了可能。隨著未來具備AI 能力的專用芯片的發(fā)展和普及，算力網(wǎng)絡(luò)除了在數(shù)據(jù)中心和邊緣數(shù)據(jù)中心實(shí)現(xiàn)資源的納管外，對(duì)于嵌入式設(shè)備的自主學(xué)習(xí)能力和自適應(yīng)能力會(huì)提出更高的要求。通過本文所提出的面向算力網(wǎng)絡(luò)的邊緣資源調(diào)度解決方案的研究，可以更好的實(shí)現(xiàn)算力網(wǎng)絡(luò)應(yīng)用于邊緣計(jì)算、物聯(lián)網(wǎng)、車聯(lián)網(wǎng)等應(yīng)用場景下的統(tǒng)一資源調(diào)度以及智能化的運(yùn)行模式。

利益沖突聲明

所有作者聲明不存在利益沖突關(guān)系。