KubeTelecom：一種面向5G網(wǎng)絡(luò)切片的多云多容器集群管理與運(yùn)維引擎

武宇亭，王旭亮，全碩

KubeTelecom：一種面向5G網(wǎng)絡(luò)切片的多云多容器集群管理與運(yùn)維引擎

武宇亭，王旭亮，全碩

（中國電信股份有限公司研究院，北京 102209）

面向運(yùn)營商多種網(wǎng)絡(luò)云化應(yīng)用的多云多容器集群管理與運(yùn)維引擎，提出并詳細(xì)介紹了KubeTelecom的設(shè)計(jì)架構(gòu)以及實(shí)現(xiàn)方案。從5G切片場景的承載需求入手，分析了KubeTelecom為上層應(yīng)用平臺提供多容器集群管理與編排能力以及數(shù)據(jù)驅(qū)動的綜合運(yùn)維能力。展望了未來電信云平臺通過集成KubeTelecom模塊，可以為多種云原生應(yīng)用提供統(tǒng)一的資源管理和運(yùn)維能力，為運(yùn)營商的多種DICT業(yè)務(wù)生態(tài)發(fā)展提供堅(jiān)實(shí)的技術(shù)支持。

多云多容器集群；云邊協(xié)同；5G網(wǎng)絡(luò)切片

1 引言

5G作為新一代移動通信技術(shù)，大量引入了云原生的理念及技術(shù)，使能新型網(wǎng)絡(luò)業(yè)務(wù)具備彈性、靈活性、敏捷性和快速迭代等傳統(tǒng)云計(jì)算業(yè)務(wù)的特點(diǎn)。雖然當(dāng)前5G建設(shè)中，主流電信設(shè)備提供商已經(jīng)基于容器、微服務(wù)等先進(jìn)技術(shù)實(shí)現(xiàn)了核心網(wǎng)元的部署。但是，以容器為代表的云原生技術(shù)在5G中的應(yīng)用還存在諸多問題。第一，當(dāng)前電信設(shè)備商基于容器安全性的考慮，當(dāng)前大多采用虛擬機(jī)容器方式進(jìn)行網(wǎng)元承載與部署，設(shè)備商的5G設(shè)備當(dāng)前仍以虛擬機(jī)的形式對外呈現(xiàn)并交付給運(yùn)營商，未對運(yùn)營商提供完全開放容器相關(guān)的開發(fā)、管理接口，要將云原生技術(shù)應(yīng)用到網(wǎng)絡(luò)業(yè)務(wù)的設(shè)計(jì)與開發(fā)、承載與編排、部署與運(yùn)維等全生命周期中，還有很長的路要走。第二，云原生網(wǎng)元部署對基礎(chǔ)設(shè)施提出了更高的技術(shù)要求，國內(nèi)運(yùn)營商對于與云原生基礎(chǔ)設(shè)施相關(guān)技術(shù)的研究還處于起步與驗(yàn)證階段，缺乏有效管理、使用、運(yùn)維、運(yùn)營多DC（datacenter）、多容器集群的相關(guān)能力。因此，本文以5G網(wǎng)絡(luò)切片應(yīng)用的需求為出發(fā)點(diǎn)，提出了一種在邊緣云和核心云之間通過多容器集群管理與運(yùn)維引擎，解決5G網(wǎng)絡(luò)切片業(yè)務(wù)的云資源橫跨多個云資源池時，帶來網(wǎng)絡(luò)切片功能所需的云原生資源管理、編排與運(yùn)維等問題。

1.1 5G網(wǎng)絡(luò)切片的云化部署與運(yùn)維需求

5G網(wǎng)絡(luò)功能采用虛擬化的部署方案，根據(jù)歐洲電信標(biāo)準(zhǔn)協(xié)會（ETSI）的網(wǎng)絡(luò)功能虛擬化（network function virtualization，NFV）工作組發(fā)布的NFV白皮書[1]以及面向5G的NFV技術(shù)白皮書[2]中的介紹，5G網(wǎng)元相比于傳統(tǒng)網(wǎng)元設(shè)備，在設(shè)備形態(tài)上主要是采用容器虛擬化技術(shù)部署在通用IT服務(wù)器之上。同時5G切片服務(wù)主要依賴于ETSI NFV提出的NFV MANO（management and orchestration）編排系統(tǒng)實(shí)現(xiàn)5G網(wǎng)絡(luò)服務(wù)的調(diào)度與編排。NFV MANO系統(tǒng)中關(guān)于5G網(wǎng)絡(luò)切片迫切需要跨云資源池云原生資源的編排管理主要依賴于虛擬基礎(chǔ)設(shè)施管理器（virtualization infrastructure manager，VIM）實(shí)現(xiàn)。VIM在傳統(tǒng)的物理機(jī)和虛擬機(jī)編排框架之上通過文獻(xiàn)[3]中的定義的CISM（container infrastructure service management）模塊負(fù)責(zé)容器服務(wù)的部署、監(jiān)控運(yùn)維以及生命周期管理，業(yè)界多數(shù)人認(rèn)為當(dāng)前開源的Kubernetes容器管理系統(tǒng)實(shí)現(xiàn)了CISM中定義的大部分工作。通過在VIM中集成和擴(kuò)展對CISM定義的工作的支持，運(yùn)營商的電信云可以實(shí)現(xiàn)對5G切片業(yè)務(wù)所須容器服務(wù)的承載。

經(jīng)過深度調(diào)研與分析，發(fā)現(xiàn)上述方案只存在理論上的可行性，距離生產(chǎn)系統(tǒng)還有較大的差距。一個面向5G網(wǎng)絡(luò)切片業(yè)務(wù)的電信云承載平臺通常需要考慮多租戶管理、多業(yè)務(wù)之間的隔離性、租戶運(yùn)維策略獨(dú)立性、業(yè)務(wù)部署的可用性、高并發(fā)、云資源的容災(zāi)與備份、容器集群的跨云資源池的分布式部署等核心要素。直接在電信云的MANO管理系統(tǒng)中集成Kubernetes容器集群的方式顯然是無法滿足上述需求的。

1.2 面向電信業(yè)務(wù)的云管平臺

運(yùn)營商通過云管平臺可以實(shí)現(xiàn)電信級VNF的云化部署。該平臺不僅重點(diǎn)實(shí)現(xiàn)了ETSI NFV MANO中VIM模塊定義的核心功能，還根據(jù)電信云特點(diǎn)實(shí)現(xiàn)了多級的監(jiān)控與告警系統(tǒng)以及級聯(lián)部署等重要功能。根據(jù)電信云的需求與特點(diǎn)，以省為單位的VIM共包含兩個層級，分別為省級節(jié)點(diǎn)與邊緣節(jié)點(diǎn)。在省級節(jié)點(diǎn)部署管理邊緣節(jié)點(diǎn)內(nèi)多個OpenStack的業(yè)務(wù)網(wǎng)關(guān)，該網(wǎng)關(guān)實(shí)現(xiàn)了對省內(nèi)多個邊緣節(jié)點(diǎn)云資源的管理與調(diào)度。在邊緣節(jié)點(diǎn)按需部署一個或多個OpenStack集群，每個集群向上層業(yè)務(wù)系統(tǒng)提供物理機(jī)、虛擬機(jī)以及容器集群服務(wù)。但是當(dāng)前云管系統(tǒng)只能提供管理與運(yùn)維多個獨(dú)立的Kubernetes集群的能力，5G切片依賴端到端資源聯(lián)動，在采用Kubernetes承載時，需要多Kubernetes集群實(shí)現(xiàn)統(tǒng)一管理與協(xié)同。因此，云管系統(tǒng)目前無法滿足5G切片的云化承載需求。解決該問題，可以從如下兩個方面考慮：一方面由5G切片業(yè)務(wù)系統(tǒng)本身實(shí)現(xiàn)對多個Kubernetes集群的管理與運(yùn)維另一方面在云管平臺內(nèi)擴(kuò)展實(shí)現(xiàn)對多個Kubernetes集群的管理與運(yùn)維能力，然后向5G切片業(yè)務(wù)系統(tǒng)提供整體的多容器集群管理與運(yùn)維服務(wù)。

1.3 多云多容器集群管理與運(yùn)維引擎

從云計(jì)算資源集約化管理與運(yùn)營以及對多種業(yè)務(wù)統(tǒng)一承載的角度，本文提出KubeTelecom，即一種在當(dāng)前統(tǒng)一云管平臺上擴(kuò)展實(shí)現(xiàn)多云多容器集群管理與運(yùn)維方案，以滿足5G切片業(yè)務(wù)的云化部署與運(yùn)維需求的方案及原型系統(tǒng)。

基于云管平臺的多容器集群管理與運(yùn)維引擎總體視圖如圖1所示，多容器集群管理與運(yùn)維引擎與現(xiàn)有云管系統(tǒng)集成部署在省級節(jié)點(diǎn)。通過與云管平臺省級網(wǎng)關(guān)交互，調(diào)用邊緣節(jié)點(diǎn)中的物理機(jī)與虛擬機(jī)資源，為5G切片業(yè)務(wù)系統(tǒng)按須創(chuàng)建多個統(tǒng)一管理和運(yùn)維的Kubernetes容器集群，滿足5G切片業(yè)務(wù)跨集群的高可用、高并發(fā)、備份與容災(zāi)以及云邊協(xié)同部署與運(yùn)維要求。具體來講，為每個5G網(wǎng)絡(luò)切片租戶提供集群組（cluster group）級別的云資源切片。在該邏輯資源切片中可以根據(jù)每個租戶的需求，實(shí)現(xiàn)多個Kubernetes集群的動態(tài)生命周期管理功能；此外為了滿足每個5G網(wǎng)絡(luò)切片租戶獨(dú)立的監(jiān)控與運(yùn)維策略管理，KubeTelecom還設(shè)計(jì)并實(shí)現(xiàn)了租戶級別的監(jiān)控、日志以及私有鏡像倉庫功能，為租戶提供最大程度的業(yè)務(wù)部署與運(yùn)營的靈活性和獨(dú)立性。

2 相關(guān)研究

5G網(wǎng)絡(luò)切片技術(shù)可以使運(yùn)營商在硬件基礎(chǔ)設(shè)施中為每個客戶按需切分出多個邏輯隔離的網(wǎng)絡(luò)切片服務(wù)。圍繞著5G網(wǎng)絡(luò)切片業(yè)務(wù)，大量的研究人員作了很多領(lǐng)域的相關(guān)工作。

圖1 基于云管平臺的多容器集群管理與運(yùn)維引擎總體視圖

現(xiàn)有文獻(xiàn)主要對網(wǎng)絡(luò)切片部署問題進(jìn)行分析，如文獻(xiàn)[4]主要針對互聯(lián)網(wǎng)或EPC（evolved packet core）等網(wǎng)絡(luò)場景及架構(gòu)，結(jié)合不同的優(yōu)化目標(biāo)對切片中的VNF部署策略優(yōu)化，如采用節(jié)點(diǎn)分割算法及業(yè)務(wù)流量感知算法對vEPC（virtualized evolved packed core）網(wǎng)絡(luò)池組虛擬網(wǎng)絡(luò)功能部署，提高網(wǎng)絡(luò)接收率、降低網(wǎng)絡(luò)資源開銷。文獻(xiàn)[5]主要針對核心網(wǎng)網(wǎng)元形成的服務(wù)功能鏈進(jìn)行網(wǎng)絡(luò)拓?fù)鋬?yōu)化以及網(wǎng)元功能部署。文獻(xiàn)[6]指出為了提高物理資源利用率，運(yùn)營商通常將不同網(wǎng)絡(luò)切片實(shí)例（network slice instance，NSI）的虛擬網(wǎng)絡(luò)功能部署在相同的服務(wù)器上，并采用資源復(fù)用技術(shù)實(shí)現(xiàn)資源的超額分配。上述文獻(xiàn)對網(wǎng)絡(luò)切片部署的研究主要集中在VNF部署策略優(yōu)化或提高資源利用率、降低能源消耗方面，未對5G切片業(yè)務(wù)應(yīng)用部署及運(yùn)維管理進(jìn)行改進(jìn)。

在現(xiàn)有5G網(wǎng)絡(luò)部署方案中，邊緣計(jì)算是網(wǎng)絡(luò)切片技術(shù)的重要支撐。文獻(xiàn)[7]指出網(wǎng)絡(luò)切片和邊緣計(jì)算融合部署方案的優(yōu)勢，方案中網(wǎng)絡(luò)切片可通過將網(wǎng)絡(luò)實(shí)體劃分成多個邏輯獨(dú)立網(wǎng)絡(luò)、為不同業(yè)務(wù)場景提供所需服務(wù)；而邊緣計(jì)算可利用網(wǎng)絡(luò)中用戶和邊緣網(wǎng)絡(luò)設(shè)備的計(jì)算和存儲功能，承載部分核心節(jié)點(diǎn)中的控制、管理、業(yè)務(wù)功能，能夠提升傳統(tǒng)移動寬帶業(yè)務(wù)能力和應(yīng)對新興的機(jī)器類通信業(yè)務(wù)。通?；谶吘売?jì)算的網(wǎng)絡(luò)切片部署方案，會在靠近移動用戶的位置上提供信息技術(shù)服務(wù)和云計(jì)算能力，將內(nèi)容分發(fā)推送到靠近用戶側(cè)，而應(yīng)用、服務(wù)和內(nèi)容都部署在高度分布的環(huán)境中，能使得運(yùn)營商根據(jù)第三方需求及網(wǎng)絡(luò)情況以低成本為用戶提供個性化網(wǎng)絡(luò)服務(wù)。

5G網(wǎng)絡(luò)切片在多數(shù)情況下除了無線網(wǎng)絡(luò)和回傳網(wǎng)絡(luò)之外，更需要考慮在邊緣UPF和5G核心網(wǎng)元部分邏輯切片的動態(tài)管理問題。文獻(xiàn)[8]中提到多云平臺統(tǒng)一運(yùn)營的關(guān)鍵技術(shù)包括多云平臺的統(tǒng)一納管、多云平臺的統(tǒng)一監(jiān)控、多云平臺的統(tǒng)一分析3個方面。但是成熟的5G網(wǎng)絡(luò)切片服務(wù)更加關(guān)注多云平臺（核心云與邊緣云）向每個租戶提供云邊協(xié)同的多容器集群生命周期管理和運(yùn)維平臺服務(wù)，具體表現(xiàn)在面對多云多容器集群時，需要對其進(jìn)行統(tǒng)一納管、監(jiān)控、分析等，實(shí)現(xiàn)對各類資源的統(tǒng)一管理運(yùn)營，獲得多云多容器環(huán)境的控制權(quán)。

基于上述研究分析，本論文重點(diǎn)關(guān)注5G網(wǎng)絡(luò)切片在核心網(wǎng)以及在邊緣節(jié)點(diǎn)部署的用戶面網(wǎng)元（UPF）的云化承載與運(yùn)維技術(shù)方案，具體包括面向5G網(wǎng)絡(luò)切片的多云多容器集群管理與運(yùn)維引擎，該引擎主要面向5G網(wǎng)絡(luò)切片場景，實(shí)現(xiàn)多云多容器集群的統(tǒng)一納管、運(yùn)營分析，滿足5G切片業(yè)務(wù)的云化部署與運(yùn)維需求。

3 系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)

通過在運(yùn)營商云管平臺的基礎(chǔ)之上增加針對多租戶的多容器集群的生命周期管理引擎設(shè)計(jì)與實(shí)現(xiàn)方案使運(yùn)營商云管平臺可以為5G網(wǎng)絡(luò)切片業(yè)務(wù)提供所需要的多容器集群的管理與運(yùn)維能力。以5G網(wǎng)絡(luò)切片應(yīng)用為例，最終實(shí)現(xiàn)在云管平臺為上層各類應(yīng)用提供綜合的云資源統(tǒng)一承載與管理運(yùn)維能力，主要從多容器集群的管理引擎和運(yùn)維引擎兩個角度分析。

3.1 多容器集群管理引擎

支持多容器集群的電信云整體方案架構(gòu)如圖2所示。在原有的電信云管及OpenStack資源池基礎(chǔ)之上引入容器集群及應(yīng)用管理模塊①，該模塊的核心是多容器集群管理引擎。通過該模塊，在當(dāng)前基于NFV的運(yùn)營商云管架構(gòu)中，增加對于容器資源②的支持，基于容器技術(shù)可以實(shí)現(xiàn)網(wǎng)元設(shè)備軟硬件功能的解耦，從而實(shí)現(xiàn)對接入網(wǎng)和核心網(wǎng)中網(wǎng)絡(luò)資源細(xì)粒度劃分[9]，進(jìn)而滿足對5G網(wǎng)絡(luò)中端到端切片靈活構(gòu)建的需求[10]。多容器集群管理引擎提供完整的API管理能力，運(yùn)營商云管可以通過調(diào)用這些API實(shí)現(xiàn)容器集群的生命周期以及容器化網(wǎng)絡(luò)切片應(yīng)用的編排調(diào)度能力。

多容器集群管理引擎創(chuàng)建的容器集群以及承載的容器化網(wǎng)絡(luò)切片運(yùn)行在傳統(tǒng)的虛擬化資源池上，為了達(dá)到上述目的，多容器集群管理引擎應(yīng)該具備和基礎(chǔ)設(shè)施資源對接的能力，從而創(chuàng)建出承載5G端到端網(wǎng)絡(luò)切片容器集群的計(jì)算、存儲、網(wǎng)絡(luò)等虛擬資源。

多容器集群管理平臺的核心是多容器集群管理與運(yùn)維引擎，基于多容器集群的5G網(wǎng)絡(luò)切片端到端承載示意圖如圖3所示，端到端的5G網(wǎng)絡(luò)切片主要依賴電信接入網(wǎng)和核心網(wǎng)，也就是說需要邊緣接入機(jī)房和核心機(jī)房承載。通過多容器集群管理引擎，可以在當(dāng)前承載5G的邊緣接入機(jī)房、核心機(jī)房的基礎(chǔ)設(shè)施之上實(shí)現(xiàn)Kubernetes容器集群生命周期的管理能力，從而為5G端到端的不同網(wǎng)絡(luò)切片（如圖3中切片1、切片2、切片3所示）的容器化承載提供基礎(chǔ)環(huán)境。通過運(yùn)維引擎，提供了集群本身及容器化應(yīng)用的可視化能力，為集群及應(yīng)用的可靠運(yùn)行提供了有力保障。

3.1.1 多容器集群引擎整體架構(gòu)

多容器集群管理引擎主要功能架構(gòu)如圖4所示，其整體分為3個部分。首先，基礎(chǔ)設(shè)施對接模塊①主要提供與電信接入邊緣機(jī)房的基礎(chǔ)設(shè)施、電信核心機(jī)房基礎(chǔ)設(shè)施的交互能力，從而為創(chuàng)建容器集群準(zhǔn)備好所需的計(jì)算、存儲、網(wǎng)絡(luò)等基礎(chǔ)設(shè)施資源；其次，集群定義模塊②主要實(shí)現(xiàn)集群所用虛擬機(jī)鏡像、規(guī)格、Master節(jié)點(diǎn)數(shù)量、Worker節(jié)點(diǎn)數(shù)量等的定義；最后，集群引導(dǎo)模塊③主要用于Kubernetes集群的創(chuàng)建等生命周期管理能力。各模塊均提供對應(yīng)的API，通過這些API可以實(shí)現(xiàn)集群的創(chuàng)建、配置和管理。

圖2 支持多容器集群的電信云整體方案架構(gòu)

圖3 基于多容器集群的5G網(wǎng)絡(luò)切片端到端承載示意圖

3.1.2 基礎(chǔ)設(shè)施對接

端到端5G網(wǎng)絡(luò)切片是一種跨域的技術(shù)方案，需要在電信統(tǒng)一的邊緣接入機(jī)房、傳輸網(wǎng)、電信核心機(jī)房的基礎(chǔ)設(shè)施上容器化多個網(wǎng)絡(luò)功能，進(jìn)而實(shí)現(xiàn)端到端的網(wǎng)絡(luò)形態(tài)。因此，多容器集群管理引擎的基礎(chǔ)設(shè)施對接模塊，如圖4中的①所示，需要和接入網(wǎng)邊緣機(jī)房以及核心網(wǎng)核心機(jī)房的基礎(chǔ)設(shè)施對接，為容器化網(wǎng)絡(luò)功能的承載提供所需要的資源。不同的基礎(chǔ)設(shè)施管理軟件提供了不同的API，為了保證和基礎(chǔ)設(shè)施對接的開放性和兼容性，基礎(chǔ)設(shè)施對接模塊通過驅(qū)動方式和不同的基礎(chǔ)設(shè)施進(jìn)行對接。在運(yùn)營商網(wǎng)絡(luò)中，基礎(chǔ)設(shè)施主要是通過開源云計(jì)算套件OpenStack實(shí)現(xiàn)，因此需要通過Cloud-Provider-OpenStack驅(qū)動實(shí)現(xiàn)和OpenStack資源池的對接。需要注意的是，電信不同機(jī)房部署的OpenStack版本不一致導(dǎo)致API存在不一致的情形，需要針對每個版本的API分別提供對應(yīng)的Cloud-Provider-OpenStack驅(qū)動插件。

圖4 多容器集群管理引擎主要功能架構(gòu)

通過Cloud-Provider-OpenStack保證了和不同基礎(chǔ)設(shè)施管理面API交互的能力，但不同的基礎(chǔ)設(shè)施通常具有不同租戶、認(rèn)證、訪問端點(diǎn)、網(wǎng)絡(luò)等信息，因此還需要用戶根據(jù)所選的驅(qū)動插件指明其所需的Cloud-Config配置信息。Cloud-Provider-OpenStack和Cloud-Config共同保證的多容器集群引擎可以按需調(diào)用基礎(chǔ)設(shè)施API創(chuàng)建所需要的資源。

3.1.3 集群定義

基礎(chǔ)設(shè)施對接模塊保證了承載Kubernetes集群所需要的基礎(chǔ)設(shè)施資源的對接調(diào)用能力，此外還需要集群定義模塊，如圖4中的②所示，該模塊的主要職責(zé)是明確要創(chuàng)建的Kubernetes容器集群的具體信息。首先，Kubernetes集群由一組基礎(chǔ)設(shè)施提供的虛擬機(jī)或者裸機(jī)組成，按角色可以分為Master節(jié)點(diǎn)、Worker節(jié)點(diǎn)以及只有受限資源的Edge節(jié)點(diǎn)，其中Edge節(jié)點(diǎn)為可選節(jié)點(diǎn)，主要通過業(yè)界開源的KubeEdge方案實(shí)現(xiàn)該節(jié)點(diǎn)上容器化應(yīng)用的編排能力。因此集群定義模塊首先需要定義創(chuàng)建的這些角色虛擬機(jī)或者裸機(jī)的鏡像以及規(guī)格信息。通常不同的Kubernetes版本對應(yīng)不同的鏡像，Kubernetes的Master節(jié)點(diǎn)、Worker節(jié)點(diǎn)、Edge節(jié)點(diǎn)可以分別指定不同的規(guī)格。其次，需要指明Kubernetes的Master節(jié)點(diǎn)的部署模式。例如，是單Master節(jié)點(diǎn)部署還是通過多個Master節(jié)點(diǎn)提供高可用的Kubernetes集群管理面。最后，還需要明確定義集群的規(guī)模，主要是定義Worker節(jié)點(diǎn)的數(shù)量與規(guī)模。用戶通過調(diào)用集群定義模塊的API完成以上集群信息的聲明，集群定模塊根據(jù)用戶的聲明并且調(diào)用基礎(chǔ)設(shè)施對接模塊，即可創(chuàng)建出承載容器集群所需要的所有云資源。

3.1.4 集群引導(dǎo)

在完成基礎(chǔ)設(shè)施對接以及Kubernetes容器集群定義后，需要集群引導(dǎo)模塊，其功能如圖5所示，該模塊主要是提供多個容器集群的生命周期管理能力。集群引導(dǎo)模塊是創(chuàng)建Kubernetes集群的核心工作引擎，其主要職責(zé)包括以下3點(diǎn)。

· 為每個集群生成集群認(rèn)證信息及配置文件，確保創(chuàng)建集群訪問的安全性。

· 初始化集群的控制平面，也就是根據(jù)用戶的集群定義完成集群組件部署。

· 將部署好的Master節(jié)點(diǎn)和Worker節(jié)點(diǎn)組合成為完整的Kubernetes集群。

圖5 集群引導(dǎo)模塊功能

對于資源受限的邊緣節(jié)點(diǎn)的管理以及其上應(yīng)用的分發(fā)，主要采用開源的KubeEdge方案。因此，對于包含Edge節(jié)點(diǎn)的Kubernetes集群，需要完成Kubernetes集群部署，再引導(dǎo)KubeEdge插件安裝Edge節(jié)點(diǎn)組件并加入上述集群中，從而形成具有云邊協(xié)同能力的Kubernetes集群。

3.2 多容器集群運(yùn)維引擎

5G網(wǎng)絡(luò)切片提供特定的網(wǎng)絡(luò)能力，滿足不同的業(yè)務(wù)場景需求，使得網(wǎng)絡(luò)的規(guī)模和復(fù)雜程度遠(yuǎn)超以往[11]；5G網(wǎng)絡(luò)切片的云化承載，相較于傳統(tǒng)專有硬件設(shè)備的網(wǎng)絡(luò)運(yùn)維，在異常檢測、故障根因分析、性能優(yōu)化等問題上變得更加復(fù)雜，此外云資源、虛擬網(wǎng)元和網(wǎng)管3個層面的分層告警降噪與快速收斂以及多層之間的故障關(guān)聯(lián)進(jìn)一步加劇網(wǎng)絡(luò)運(yùn)維工作難度。本文主要針對5G網(wǎng)絡(luò)切片業(yè)務(wù)所需云資源側(cè)的多云多容器集群，通過對基礎(chǔ)設(shè)施云以及多容器集群資源的監(jiān)控告警等數(shù)據(jù)進(jìn)行采集，并利用數(shù)據(jù)科學(xué)、人工智能等技術(shù)對這些數(shù)據(jù)進(jìn)行處理及分析，輔助多容器管理集群對5G網(wǎng)絡(luò)切片整個生命周期的管理，實(shí)現(xiàn)效率提升、質(zhì)量保障和成本優(yōu)化的目標(biāo)。

3.2.1 多容器集群運(yùn)維引擎整體架構(gòu)

多容器集群運(yùn)維引擎整體架構(gòu)方案如圖6所示，其整體分為3個部分。首先是數(shù)據(jù)采集與存儲模塊，主要實(shí)現(xiàn)從裸機(jī)、虛擬機(jī)、容器資源中采集存儲指標(biāo)、告警、日志、事件等數(shù)據(jù)，以及對外提供查詢、檢索能力。其次是數(shù)據(jù)處理模塊，根據(jù)不同的運(yùn)維場景對采集的基礎(chǔ)數(shù)據(jù)進(jìn)行清洗、歸類、聚合，構(gòu)建全面、標(biāo)準(zhǔn)、精細(xì)、統(tǒng)一的數(shù)據(jù)模型。最后是數(shù)據(jù)分析模塊，使用機(jī)器學(xué)習(xí)、人工智能的方法，在異常檢測、根因分析、趨勢預(yù)測等場景中代替人工進(jìn)行決策，提升運(yùn)維效率。

3.2.2 數(shù)據(jù)采集與存儲

數(shù)據(jù)采集與存儲模塊需要滿足大規(guī)模集群下裸機(jī)、虛擬機(jī)、容器運(yùn)維數(shù)據(jù)的采集、存儲與檢索任務(wù)。采集數(shù)據(jù)的主要類型分為監(jiān)控?cái)?shù)據(jù)和日志數(shù)據(jù)兩類。數(shù)據(jù)采集與存儲架構(gòu)基于開源社區(qū)的主流解決方案設(shè)計(jì)。監(jiān)控?cái)?shù)據(jù)的采集與存儲架構(gòu)如圖7所示，通過搭建指標(biāo)及報(bào)警監(jiān)控解決方案Prometheus集群對多容器集群運(yùn)維數(shù)據(jù)進(jìn)行采集；使用具有長期存儲的高可用Prometheus解決方案Thanos提供的Query和Object Storage組件進(jìn)行統(tǒng)一的查詢、存儲；使用控制中心組件完成整個采集過程的控制及管理，包括配置Prometheus集群的采集對象、提供數(shù)據(jù)監(jiān)控視圖、基于監(jiān)控指標(biāo)的基礎(chǔ)告警等。日志數(shù)據(jù)的采集與存儲架構(gòu)如圖8所示，使用輕量級數(shù)據(jù)采集器Filebeat以邊車方式采集日志文件，通過分布式消息系統(tǒng)Kafka組件匯總?cè)罩緮?shù)據(jù)，數(shù)據(jù)處理管道Logstash組件將數(shù)據(jù)轉(zhuǎn)發(fā)到分布式搜索及分析引擎ElasticSearch集群中；使用數(shù)據(jù)采集系統(tǒng)Fluentd組件采集標(biāo)準(zhǔn)日志輸出流到ElasticSearch集群中；構(gòu)建ElasticSearch集群統(tǒng)一實(shí)現(xiàn)日志的持久化存儲及檢索。

圖6 多容器集群運(yùn)維引擎整體架構(gòu)方案

圖7 監(jiān)控?cái)?shù)據(jù)的采集與存儲架構(gòu)

圖8 日志數(shù)據(jù)的采集與存儲架構(gòu)

3.2.3 數(shù)據(jù)處理

數(shù)據(jù)處理模塊是對多源數(shù)據(jù)進(jìn)行統(tǒng)一的數(shù)據(jù)治理，為人工決策、智能運(yùn)維提供堅(jiān)實(shí)的數(shù)據(jù)基礎(chǔ)。該模塊主要包括數(shù)據(jù)清洗、數(shù)據(jù)歸類存儲、數(shù)據(jù)建模等部分[12]。數(shù)據(jù)清洗以數(shù)據(jù)去重、噪聲數(shù)據(jù)識別、缺失值處理為主，構(gòu)建高質(zhì)量數(shù)據(jù)。數(shù)據(jù)歸類存儲實(shí)現(xiàn)多維度監(jiān)控?cái)?shù)據(jù)的統(tǒng)一化[13]，以CPU的使用率為例，數(shù)據(jù)采集與存儲模塊可以收集到一臺裸機(jī)及之上運(yùn)行的虛擬機(jī)和容器3個維度的CPU使用率數(shù)據(jù)，它們之間是無關(guān)聯(lián)的，如果不進(jìn)行數(shù)據(jù)歸類，無法反映數(shù)據(jù)間的相關(guān)性，數(shù)據(jù)歸類存儲示意圖如圖9所示，可以進(jìn)行統(tǒng)一化描述，更好地解決故障診斷及性能優(yōu)化。數(shù)據(jù)建模根據(jù)具體的運(yùn)維場景對數(shù)據(jù)進(jìn)行建模，以根因分析為例，端到端的5G網(wǎng)絡(luò)切片業(yè)務(wù)會經(jīng)過多個容器集群，數(shù)據(jù)建模示例如圖10所示，將每個容器集群的運(yùn)維數(shù)據(jù)聚合匯總起來，構(gòu)建一條完整的調(diào)用連，可以更好地解決根因分析、性能瓶頸等問題。

圖9 數(shù)據(jù)歸類存儲示意圖

圖10 數(shù)據(jù)建模示例

3.2.4 數(shù)據(jù)分析

數(shù)據(jù)分析模塊主要應(yīng)用于多云多容器集群的效率提升、質(zhì)量保證、成本管理等場景[14]，通過智能決策、異常檢測、故障預(yù)測、資源優(yōu)化等技術(shù)[15]，提升多容器集群的運(yùn)行質(zhì)量、減少運(yùn)營成本。數(shù)據(jù)分析模塊分為計(jì)算分析組件和算法研發(fā)組件，數(shù)據(jù)分析模塊架構(gòu)示意圖如圖11所示。其中計(jì)算、分析組件包括離線計(jì)算和在線計(jì)算兩部分，主要為數(shù)據(jù)分析模塊提供計(jì)算能力，可以對歷史數(shù)據(jù)進(jìn)行離線分析處理，對實(shí)時數(shù)據(jù)進(jìn)行在線分析處理。算法研發(fā)平臺分為標(biāo)記平臺、訓(xùn)練平臺、評估驗(yàn)證平臺、算法開發(fā)框架等部分，主要為數(shù)據(jù)分析模塊提供算法能力，可以滿足不同場景下的算法需求。

圖11 數(shù)據(jù)分析模塊架構(gòu)示意圖

4 關(guān)鍵技術(shù)討論

4.1 面向云邊協(xié)同的監(jiān)控和日志方案

面向云邊協(xié)同監(jiān)控和日志方案的重點(diǎn)是解決邊緣節(jié)點(diǎn)的數(shù)據(jù)采集問題，邊緣節(jié)點(diǎn)的網(wǎng)絡(luò)和資源受限是邊緣側(cè)數(shù)據(jù)采集的主要挑戰(zhàn)。在第3.2節(jié)的方案中，Promethues部署在遠(yuǎn)端，對Worker節(jié)點(diǎn)的監(jiān)控?cái)?shù)據(jù)采集是通過云端節(jié)點(diǎn)對外暴露Metrics接口，Prometheus直接請求云端節(jié)點(diǎn)的Metrcis接口實(shí)現(xiàn)的；云端節(jié)點(diǎn)的日志數(shù)據(jù)采集是通過直接部署日志采集組件Fluend，由Fluend上報(bào)給ElasticSearch集群實(shí)現(xiàn)的。但是，在邊緣環(huán)境中，邊節(jié)點(diǎn)通常以有限的計(jì)算資源運(yùn)行在私有網(wǎng)段，不提供公網(wǎng)IP地址，云端組件無法直連。因此，Promethues對邊節(jié)點(diǎn)無法按照云端方式直接采集監(jiān)控?cái)?shù)據(jù)。邊節(jié)點(diǎn)也因?yàn)橛?jì)算資源受限，不適宜直接部署Fluentd這樣高資源消耗的組件采集日志數(shù)據(jù)。

本節(jié)將基于KubeEdge給出邊緣節(jié)點(diǎn)監(jiān)控和日志數(shù)據(jù)的采集方案，方案架構(gòu)如圖12所示。其中，API服務(wù)是Kubernetes原生組件；Cloud Core是KubeEdge的云端組件，負(fù)責(zé)邊緣節(jié)點(diǎn)管理，如上報(bào)邊緣節(jié)點(diǎn)信息；Edge Core是KubeEdge的邊緣組件，運(yùn)行在邊緣節(jié)點(diǎn)，負(fù)責(zé)管理邊緣容器，如容器的監(jiān)控信息和日志信息獲取，并分別通過監(jiān)控接口和日志接口對外提供訪問。Cloud Core和Edge Core基于Websocket建立消息隧道實(shí)現(xiàn)云邊通信，并且已默認(rèn)實(shí)現(xiàn)了監(jiān)控消息隧道和日志消息隧道用于傳遞Edge Core獲取的容器監(jiān)控信息和日志信息?；贙ubeEdge的現(xiàn)有模塊，本文邊緣節(jié)點(diǎn)數(shù)據(jù)采集方案和實(shí)現(xiàn)步驟如下。

圖12 邊緣節(jié)點(diǎn)監(jiān)控與日志數(shù)據(jù)采集架構(gòu)

4.2 面向跨域的多容器集群及應(yīng)用的統(tǒng)一管理

如前文所述，5G網(wǎng)絡(luò)切片是一種端到端的網(wǎng)絡(luò)解決方案，其實(shí)現(xiàn)依賴電信接入、核心等多個機(jī)房的跨域網(wǎng)絡(luò)環(huán)境。要實(shí)現(xiàn)端到端5G網(wǎng)絡(luò)切片的靈活管理，除了通過多容器管理與運(yùn)維引擎提供5G網(wǎng)絡(luò)切片的多容器集群承載環(huán)境，同時還需要跨域的多集群統(tǒng)一管理以及應(yīng)用的統(tǒng)一編排與部署能力。

第一，通過跨域的多集群統(tǒng)一管理可以實(shí)現(xiàn)對電信接入、核心等多個機(jī)房中容器集群的統(tǒng)一管理能力。容器集群及基于集群聯(lián)邦CRD的應(yīng)用管理模塊，除了實(shí)現(xiàn)容器集群生命周期的管理能力以及對全局集群的統(tǒng)一監(jiān)控能力，還提供了多集群的統(tǒng)一管理能力。

多集群統(tǒng)一管理，一方面提供了多集群統(tǒng)一的訪問入口，基于此入口可以提供多集群一致的訪問與管理視圖，簡化管理員多集群的管理復(fù)雜度；另一方面可以實(shí)現(xiàn)全局的賬號與權(quán)限管理，從而提供面向CT場景的多租戶能力。除此以外，多集群統(tǒng)一管理還提供項(xiàng)目管理機(jī)制，具有相應(yīng)權(quán)限的管理員或者普通用戶，可以在對應(yīng)集群上創(chuàng)建項(xiàng)目，并在對應(yīng)項(xiàng)目中創(chuàng)建容器化工作負(fù)載、微服務(wù)、面向CT的DevOps等應(yīng)用。

第二，跨域應(yīng)用的統(tǒng)一管理。網(wǎng)絡(luò)切片端到端形態(tài)特點(diǎn)，要求實(shí)現(xiàn)跨域容器化應(yīng)用的統(tǒng)一管理能力?；谌萜鞫嗉阂约癋ederation V2聯(lián)邦技術(shù)，可以實(shí)現(xiàn)全局的應(yīng)用統(tǒng)一編排、部署、運(yùn)維能力，從而滿足網(wǎng)絡(luò)切片的部署需求。

通過Federation V2組建的聯(lián)邦集群組成示意圖如圖13所示，有一個集群是Host集群，其余集群是Member集群，在Host集群中，通過Kubernetes提供的CRD機(jī)制實(shí)現(xiàn)聯(lián)邦資源的擴(kuò)展，這些聯(lián)邦資源由對應(yīng)的控制器管理，實(shí)現(xiàn)跨集群的應(yīng)用編排、資源同步等功能。用戶基于擴(kuò)展CRD提供的API即可實(shí)現(xiàn)聯(lián)邦資源的創(chuàng)建。

圖13 聯(lián)邦集群組成示意圖

5 結(jié)束語

本論文通過對5G網(wǎng)絡(luò)切片場景云化承載需求的分析，對于以容器及多容器集群等云原生技術(shù)在電信行業(yè)的應(yīng)用進(jìn)行了積極的探索，通過自主設(shè)計(jì)與研發(fā)具備云邊協(xié)同、多租戶隔離、多容器集群高可用部署、敏捷管理與運(yùn)維的KubeTelecom，滿足了5G切片云化承載的核心需求，使得云管平臺初步具備了對以5G網(wǎng)絡(luò)切片為例的云原生應(yīng)用系統(tǒng)的統(tǒng)一云化承載與運(yùn)維的系統(tǒng)原型能力。未來將重點(diǎn)驗(yàn)證KubeTelecom引擎與統(tǒng)一云管平臺的系統(tǒng)集成工作。同時以5G網(wǎng)絡(luò)切片業(yè)務(wù)為抓手，在具體的現(xiàn)網(wǎng)試點(diǎn)工作中逐步提高KubeTelecom與統(tǒng)一云管平臺的適配性和相關(guān)功能模塊的延伸研發(fā)工作。根據(jù)現(xiàn)網(wǎng)試驗(yàn)結(jié)果，不斷總結(jié)和完善KubeTelecom，使其逐步具備承載大規(guī)模商用的云原生業(yè)務(wù)系統(tǒng)的穩(wěn)定性與可靠性。

[1] ETSI NFV ISG. Network functions virtualization-introduction white paper[R]. 2012.

[2] ETSI NFV ISG. Network functions virtualization white paper on NFV priorities for 5G[R]. 2017.

[3] ETSI NFV ISG. Report on the enhancement of the NFV architecture towards “Cloud-native” and “PaaS”[R]. 2019.

[4] 湯紅波, 袁泉, 盧干強(qiáng), 等. 一種支持節(jié)點(diǎn)分割的vEPC虛擬網(wǎng)絡(luò)功能部署模型[J]. 電子與信息學(xué)報(bào), 2017, 39(3): 546-553.

TANG H B, YUAN Q, LU G Q, et al. A model for virtualized network function deployment based on node-splitting in vEPC[J]. Journal of Electronics & Information Technology, 2017, 39(3): 546-553.

[5] 王琛, 湯紅波, 游偉, 等. 一種基于動態(tài)規(guī)劃的vEPC服務(wù)功能鏈部署方法[J]. 計(jì)算機(jī)應(yīng)用研究, 2018, 35(7): 2106-2109.

WANG C, TANG H B, YOU W, et al. Method for service function chaining deployment based on dynamic programming in vEPC[J]. Application Research of Computers, 2018, 35(7): 2106-2109.

[6] 黃開枝, 潘啟潤, 袁泉, 等. 基于性能感知的網(wǎng)絡(luò)切片部署方法[J]. 通信學(xué)報(bào), 2019, 40(8): 114-122.

HUANG K Z, PAN Q R, YUAN Q, et al. Method of network slicing deployment based on performance-aware[J]. Journal on Communications, 2019, 40(8): 114-122.

[7] 劉健. 5G邊緣計(jì)算和網(wǎng)絡(luò)切片技術(shù)[J]. 電子技術(shù)與軟件工程, 2019(12): 1.

LIU J. 5g edge computing and network slicing technology[J]. Electronic Technology & Software Engineering, 2019(12): 1.

[8] 黎宇. 多云平臺的統(tǒng)一運(yùn)營及關(guān)鍵技術(shù)研究[J]. 信息通信, 2019, 32(6): 232-233.

LI Y. Research on unified operation and key technologies of multi cloud platform[J]. Information & Communications, 2019, 32(6): 232-233.

[9] COTRONEO D, DE SIMONE L, NATELLA R. NFV-bench: a dependability benchmark for network function virtualization systems[J]. IEEE Transactions on Network and Service Management, 2017, 14(4): 934-948.

[10] 安琪, 劉艷萍, 孫茜, 等. 基于SDN與NFV的網(wǎng)絡(luò)切片架構(gòu)[J]. 電信科學(xué), 2016, 32(11): 119-126.

AN Q, LIU Y P, SUN Q, et al. Network slicing architecture based on SDN and NFV[J]. Telecommunications Science, 2016, 32(11): 119-126.

[11] 張巍. 5G核心網(wǎng)切片運(yùn)維管理關(guān)鍵技術(shù)研究[J]. 數(shù)字通信世界, 2020(3): 39, 68.

ZHANG W. Research on key technologies of 5G core network slice operation and maintenance management[J]. Digital Communication World, 2020(3): 39, 68.

[12] 李杰. IT運(yùn)維監(jiān)控系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[D]. 成都: 電子科技大學(xué), 2020.

LI J. Design and realization of the network maintenance and monitoring system[D]. Chengdu: University of Electronic Science and Technology of China, 2020.

[13] 冷喜武, 李平, 霍雪松, 等. 智能電網(wǎng)監(jiān)控運(yùn)行大數(shù)據(jù)分析系統(tǒng)統(tǒng)一建模方法研究[J]. 電力大數(shù)據(jù), 2019, 22(7): 48-54.

LENG X W, LI P, HUO X S, et al. Research on unified modeling method of big data analysis system for monitoring operation of smartpower grid[J]. Power Systems and Big Data, 2019, 22(7): 48-54.

[14] 肖哲. 人工智能在5G網(wǎng)絡(luò)中的應(yīng)用[J]. 中國電子科學(xué)研究院學(xué)報(bào), 2020, 15(8): 746-749.

XIAO Z. Application of artificial intelligence in 5G Network[J]. Journal of China Academy of Electronics and Information Technology, 2020, 15(8): 746-749.

[15] 林舒剛. 5G網(wǎng)絡(luò)智能運(yùn)維研究[J]. 廣東通信技術(shù), 2020, 40(3): 32-35.

LIN S G. Research on intelligent operation and maintenance of 5G network[J]. Guangdong Communication Technology, 2020, 40(3): 32-35.

KubeTelecom: a multi-cloud multi-container cluster management and operation engine for 5G network slicing

WU Yuting, WANG Xuliang, QUAN Shuo

Research Institute of China Telecom Co., Ltd., Beijing 102209, China

KubeTelecom design architecture and implementation were proposed and introduced in detail, which was for multi-cloud multi-container cluster management and operation and maintenance engine operators’ multiple network cloud applications. Based on the bearer requirements of the 5G slicing scenario, KubeTelecom provided the upper-layer application platform with multi-container cluster management and orchestration capabilities and data-driven comprehensive operation and maintenance capabilities were analyzed in detail. The future telecom cloud platform integrates the KubeTelecom module to provide unified resource management and operation and maintenance capabilities for multiple cloud-native applications, and provide solid technical support for the development of operators’ multiple DICT business ecosystems.

multi-cloud multi-container cluster, cloud edge collaboration, 5G network slice

TP393

A

10.11959/j.issn.1000?0801.2021276

2021?10?20；

2021?12?10

武宇亭（1986?），男，中國電信股份有限公司研究院工程師，主要研究方向?yàn)樵凭W(wǎng)融合、邊緣計(jì)算、分布式存儲。

王旭亮（1986?），男，中國電信股份有限公司研究院高級工程師，主要研究方向?yàn)樵凭W(wǎng)融合、云數(shù)據(jù)中心網(wǎng)絡(luò)和邊緣計(jì)算等。

全碩（1991?），男，中國電信股份有限公司研究院工程師，主要研究方向?yàn)樵凭W(wǎng)融合、云計(jì)算與大數(shù)據(jù)和云網(wǎng)運(yùn)營等。