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

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

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

引 言

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

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

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

1 算力網(wǎng)絡

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

圖1 算力網(wǎng)絡技術架構Fig.1 Technology architecture on computing power network

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

2 輕量級云原生架構

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

圖2 Kubernetes 技術架構Fig.2 Technology architecture on Kubernetes

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

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

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

圖3 K3S 技術架構Fig.3 Technology architecture on K3S

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

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

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

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

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

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

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

3.2 基于ARM 的容器部署

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

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

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

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

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

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

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

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

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

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

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

4 應用場景

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

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

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

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

5 結論和展望

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

利益沖突聲明

所有作者聲明不存在利益沖突關系。