5G云原生部署機(jī)制研究與仿真

陳梅 蘇晨 趙靜雅 高震宇

摘要：為推動(dòng)目前現(xiàn)有開源5G核心網(wǎng)的進(jìn)展，文章通過研究云原生5G核心網(wǎng)原型系統(tǒng)平臺(tái)的構(gòu)建，以達(dá)到現(xiàn)有網(wǎng)絡(luò)功能的容器化實(shí)現(xiàn)。首先構(gòu)建簡易的開源5G核心網(wǎng)，通過Kubernetes（簡稱K8s）自帶的四層負(fù)載均衡和七層負(fù)載均衡，驗(yàn)證模擬多并發(fā)時(shí)系統(tǒng)的負(fù)載均衡能力及擴(kuò)縮容能力;將核心網(wǎng)通過所搭建的核心網(wǎng)的NGAP口STCP口的地址進(jìn)行連接，進(jìn)行整個(gè)系統(tǒng)的調(diào)試，通過沖石通信模擬器通過設(shè)置UE數(shù)目，仿真基站進(jìn)行整個(gè)系統(tǒng)的可靠性測(cè)試。進(jìn)行負(fù)載均衡驗(yàn)證，完成云化環(huán)境中的動(dòng)態(tài)擴(kuò)縮容算法的研究，以實(shí)現(xiàn)具備高可靠的云原生5G 核心網(wǎng)系統(tǒng)平臺(tái)。

關(guān)鍵詞：云原生;5G核心網(wǎng);Kubernetes;動(dòng)態(tài)擴(kuò)縮容;負(fù)載均衡

中圖分類號(hào)：TP393? ? ? 文獻(xiàn)標(biāo)識(shí)碼：A

文章編號(hào)：1009-3044（2022）15-0049-03

1 引言

全球目前已經(jīng)進(jìn)入5G時(shí)代，中國5G用戶數(shù)量突破一億，中國的5G商用取得了矚目的成就。5G覆蓋率大，傳輸速率、延遲、帶寬均有不同程度的提升。隨著2020年6月，3GPPR165G核心網(wǎng)標(biāo)準(zhǔn)凍結(jié)，5G標(biāo)準(zhǔn)的完善和商用的加速推進(jìn)，對(duì)網(wǎng)絡(luò)提出了更高的要求[1]。一方面，5G業(yè)務(wù)包含高速率、大連接和低時(shí)延等場(chǎng)景，將使移動(dòng)通信深入到行業(yè)領(lǐng)域，業(yè)務(wù)的不確定性要求網(wǎng)絡(luò)架構(gòu)具備差異化服務(wù)和靈活的資源調(diào)度能力;另一方面，IT技術(shù)的快速迭代驅(qū)動(dòng)網(wǎng)絡(luò)不斷變革，5G系統(tǒng)架構(gòu)借鑒IT領(lǐng)域“微服務(wù)”的設(shè)計(jì)理念，采用服務(wù)化架構(gòu)（SBA）將網(wǎng)絡(luò)功能拆解為獨(dú)立的NF（Network Function），對(duì)外提供自包含、自管理、可重用的網(wǎng)絡(luò)功能服務(wù)，網(wǎng)絡(luò)服務(wù)在業(yè)務(wù)功能上解耦，并通過統(tǒng)一類型的服務(wù)化接口實(shí)現(xiàn)調(diào)用，使網(wǎng)絡(luò)具備敏捷部署、彈性伸縮和靈活編排能力[2]。隨著容器化技術(shù)、Docker及Kubernetes（簡稱K8s）等技術(shù)的廣泛應(yīng)用，云原生技術(shù)走向成熟，其作為下一代云計(jì)算的核心組件，給出的體系和方法為網(wǎng)絡(luò)建設(shè)提供了方向，其核心設(shè)計(jì)理念是網(wǎng)絡(luò)架構(gòu)服務(wù)化、軟件架構(gòu)微服務(wù)化，其網(wǎng)絡(luò)云化本質(zhì)是將電信網(wǎng)絡(luò)和IT技術(shù)深度融合[3]，從而降低成本，從軟硬件解耦的虛擬化開始，軟件通過虛擬化和硬件分離，之后通過統(tǒng)一云平臺(tái)的資源池化[4]，實(shí)現(xiàn)平臺(tái)內(nèi)的資源統(tǒng)一編排和調(diào)度，最后同各云原生的功能組件化，利用服務(wù)化架構(gòu)，為上層應(yīng)用提供服務(wù)。當(dāng)前傳統(tǒng)運(yùn)營商的網(wǎng)絡(luò)建設(shè)處在虛擬化到資源池化的優(yōu)化階段，從規(guī)劃和部署情況看，仍面臨多廠商煙囪式部署、統(tǒng)一云平臺(tái)集成、網(wǎng)絡(luò)自動(dòng)化水平等多方面挑戰(zhàn)，尚未充分發(fā)揮云化網(wǎng)絡(luò)帶來的全部優(yōu)勢(shì)[5-6]。所以對(duì)5G云原生部署有必要進(jìn)行深入研究。

2系統(tǒng)工作原理

該系統(tǒng)通過將5G核心網(wǎng)元部署到Docker上，之后通過K8s中的Pod將Docker中運(yùn)行的核心網(wǎng)鏡像進(jìn)行管控，對(duì)于5G核心網(wǎng)內(nèi)部的工作原理由于過于冗長，且不是本文主要內(nèi)容，所以不再進(jìn)行解釋。如果對(duì)AMF、SMF、UDR、AUSF的請(qǐng)求過多，會(huì)通過K8s中的HPA自動(dòng)擴(kuò)縮容進(jìn)行Pod的增加或者減少，同時(shí)如果哪個(gè)節(jié)點(diǎn)出現(xiàn)問題，通過K8s自帶的負(fù)載均衡算法也會(huì)將上面節(jié)點(diǎn)的Pod轉(zhuǎn)移至其他的節(jié)點(diǎn)，在這里用一個(gè)master、兩個(gè)node節(jié)點(diǎn)進(jìn)行管控，通過將一個(gè)節(jié)點(diǎn)關(guān)閉調(diào)度，觀察其中的Pod轉(zhuǎn)移及新增Pod的情況。除此之外，通過一個(gè)新增的虛擬機(jī)對(duì)系統(tǒng)產(chǎn)生過多的激增請(qǐng)求，觀察K8s基于HPA對(duì)新增的Pod節(jié)點(diǎn)的調(diào)度。

2.1系統(tǒng)工作流程圖

2.2負(fù)載均衡

2.2.1四層負(fù)載均衡

使用IP+Port 接收，將其傳輸至相應(yīng)的服務(wù)，并在傳輸層進(jìn)行操作?？蛻舳撕头?wù)器進(jìn)行一次TCP連接。該算法類似于路由器的作用。主要是在四層和七層起作用，而四層和七層的概念來自O(shè)SI七層模型。該算法主要是利用DNS解析，通過Kube-Proxy實(shí)現(xiàn)。該算法默認(rèn)解析到虛擬IP是一個(gè)Service服務(wù)，該虛擬IP通過Kube-Proxy將其均衡到各個(gè)不同的Pod上。Pod的IP不穩(wěn)定，每次重啟Pod后會(huì)隨機(jī)改變，但Service的IP是穩(wěn)定的，所以主要是通過Node Port暴露服務(wù)，使相應(yīng)的Pod可以被外界所訪問。Service根據(jù)Kube-Proxy不同的代理，展現(xiàn)出不同的性能。

1）User space模式

Service的請(qǐng)求會(huì)從用戶空間進(jìn)入內(nèi)核，然后再返回用戶空間，由 Kube-Proxy完成后端的選擇和代理工作，但這樣耗費(fèi)的流量和資源十分巨大，導(dǎo)致性能急劇下降。需要注意的是：請(qǐng)求到達(dá)IPtables時(shí)會(huì)進(jìn)入內(nèi)核，而 Kube-Proxy主要作用是監(jiān)聽用戶的工作狀態(tài)。因此請(qǐng)求會(huì)相應(yīng)形成從用戶到內(nèi)核再到用戶的一個(gè)傳遞過程， 從而降低了服務(wù)性能，因此，User space 性能差。

2）IPtables模式

通過IPtables實(shí)現(xiàn)一個(gè)四層的TCP連接;Kube-Proxy負(fù)責(zé)創(chuàng)建IPtables 中NAT的相應(yīng)規(guī)則，但不負(fù)責(zé)流量轉(zhuǎn)發(fā)。這種基于IPtables的負(fù)載均衡操作簡單，但是當(dāng)集群規(guī)模大，導(dǎo)致請(qǐng)求響應(yīng)變得特別多時(shí)，這種基于IPtables負(fù)載均衡的性能就會(huì)相應(yīng)變差。當(dāng)添加一個(gè)Service時(shí)，命令行工具需要從內(nèi)核中讀取當(dāng)前所有的Service列表，然后重新編輯列表，之后再將內(nèi)核中的列表進(jìn)行更新。例如：假如要添加N個(gè)Service同時(shí)，相應(yīng)的復(fù)雜度為 O（N^2） 。但是在轉(zhuǎn)發(fā)面上，所有 Service IP 地址組成了一個(gè)list，每一個(gè)報(bào)文都需要查找這個(gè)list，找到相應(yīng)的IP，才可以進(jìn)行下一步操作。假如一個(gè) IP在 list 末尾，就需要遍歷 N 次，復(fù)雜度為 O（N/2）。

這種四層負(fù)載均衡也有一些缺點(diǎn)，缺點(diǎn)如下：

Service如果有很多，并且為了暴露端口供外面的主機(jī)訪問，需要綁定Node的主機(jī)端口，外圍的相應(yīng)端口必須開放從而進(jìn)行服務(wù)調(diào)用。為解決這個(gè)問題，比較通用的方式是通過一個(gè)外部的負(fù)載均衡器，例如Nginx，綁定相應(yīng)的端口號(hào)，再根據(jù)相應(yīng)的地址接口，向后面的Service IP進(jìn)行一系列的轉(zhuǎn)發(fā)操作。7ABD40FB-A7EB-4270-A803-81E2C2F84682

Service的同時(shí)存在著很多分發(fā)策略：例如輪詢機(jī)制。將請(qǐng)求轉(zhuǎn)發(fā)到后端的各個(gè)Pod中，由此衍生出了加權(quán)輪詢，即給不同的Pod加入權(quán)重，幫助加速實(shí)現(xiàn)負(fù)載均衡。

2.2.2七層負(fù)載均衡

七層負(fù)載均衡主要來自現(xiàn)代通信的OSI七層模型中的第七層應(yīng)用層，負(fù)載均衡器根據(jù)虛擬的URL和主機(jī)名接收或者發(fā)送請(qǐng)求，將請(qǐng)求進(jìn)行相應(yīng)的負(fù)載均衡處理后，進(jìn)行相應(yīng)轉(zhuǎn)發(fā)，最終實(shí)現(xiàn)整個(gè)系統(tǒng)的負(fù)載均衡。

七層負(fù)載均衡通過建立兩次TCP連接進(jìn)行相應(yīng)的負(fù)載均衡?？蛻舻截?fù)載均衡器，負(fù)載均衡器依據(jù)于相關(guān)的請(qǐng)求中所傳輸?shù)膬?nèi)容主要來自URL或Cookie中的信息，選擇合適的負(fù)載均衡的算法，選擇相應(yīng)的服務(wù)器;建立負(fù)載均衡器到服務(wù)器之間的連接。但必須注意的是負(fù)載均衡設(shè)備需要先實(shí)現(xiàn)服務(wù)器和客戶端建立TCP連接后，客戶端發(fā)送的含有應(yīng)用層內(nèi)容的報(bào)文會(huì)被接受，系統(tǒng)會(huì)根據(jù)該報(bào)文中的特定字段，通過負(fù)載均衡設(shè)備設(shè)置的服務(wù)器選擇方式，內(nèi)部服務(wù)器會(huì)被最終確定，反向代理也由此而來。

Ingress 是K8s的一種資源對(duì)象，Ingress允許外部訪問K8s服務(wù)，通過創(chuàng)建規(guī)則集合配置訪問權(quán)限，這些規(guī)則定義了相應(yīng)的服務(wù)被訪問的權(quán)限設(shè)置，支持 HTTP 和 HTTPS 協(xié)議;Ingress 配置相應(yīng)的URL訪問設(shè)置、同時(shí)設(shè)立相關(guān)的主機(jī)名等一系列配置，促使系統(tǒng)正常運(yùn)行。

七層負(fù)載均衡相較于四層負(fù)載均衡CPU占用率更高，但并不會(huì)導(dǎo)致服務(wù)器性能下降。七層負(fù)載均衡可以讓負(fù)載均衡器做出更恰當(dāng)?shù)姆磻?yīng)抉擇，并通過相應(yīng)操作對(duì)于相關(guān)內(nèi)容進(jìn)行優(yōu)化，例如壓縮、加密等。七層負(fù)載均衡同樣可以利用buffering等一些操作卸載其他服務(wù)器的壞連接，從而提高性能。

Ingress-controller用來實(shí)現(xiàn)反向代理和負(fù)載均衡。

其主要作用方式為：通過監(jiān)聽相應(yīng)API對(duì)象里的配置規(guī)則，轉(zhuǎn)化成相應(yīng)的配置，并對(duì)外部提供服務(wù)。

對(duì)于上述負(fù)載而言，還有若干種均衡算法：

第一種：輪詢均衡。負(fù)載均衡器將任何一次來自客戶端的請(qǐng)求輪流平均分配給其內(nèi)部中的服務(wù)器，每次服務(wù)請(qǐng)求到達(dá)時(shí)，依次查找內(nèi)部服務(wù)器，找到?jīng)]有負(fù)載的服務(wù)器，這種算法在服務(wù)器配置均衡的情況下，大有裨益。

第二種：權(quán)重輪詢均衡。由于每組組服務(wù)器中不同的服務(wù)器處理的性能有很大的差別，如果給每個(gè)服務(wù)器分配不同的權(quán)值，服務(wù)器可以因?yàn)椴煌臋?quán)值而規(guī)劃相應(yīng)的負(fù)載。

第三種：隨機(jī)均衡（Random）。把來自網(wǎng)絡(luò)的請(qǐng)求通過哈希等相關(guān)算法不均勻地分配給內(nèi)部中的多個(gè)服務(wù)器。

第四種：最少連接數(shù)均衡。是指客戶端的每一次服務(wù)請(qǐng)求在使服務(wù)器工作的時(shí)間大有不同，一旦工作時(shí)間變得更長，如果僅是簡單地套用相關(guān)的輪詢和隨機(jī)均衡算法，不同服務(wù)器的會(huì)有極大不同，隨之帶來的負(fù)載均衡仍舊有很大的問題。

第五種：處理能力均衡。這種負(fù)載均衡算法是一種在七層負(fù)載下使用較多的均衡算法，該均衡算法的主要原理是依據(jù)相關(guān)的系統(tǒng)指標(biāo)，將請(qǐng)求的服務(wù)分發(fā)給負(fù)載較輕的服務(wù)器，該指標(biāo)包括服務(wù)器的處理性能和網(wǎng)絡(luò)的擁塞情況，所以更因地制宜、性能更優(yōu)秀。

3自動(dòng)擴(kuò)縮容協(xié)調(diào)機(jī)制

擴(kuò)縮容算法主要分為自動(dòng)擴(kuò)縮容和手動(dòng)擴(kuò)縮容，由于手動(dòng)擴(kuò)縮容依賴于命令直接禁止一個(gè)節(jié)點(diǎn)的調(diào)度，從而將pod分配至其他節(jié)點(diǎn)，沒有較多的內(nèi)部原理，所以不再贅述，這里主要介紹基于HPA的自動(dòng)擴(kuò)縮容算法。

自動(dòng)擴(kuò)縮容協(xié)調(diào)：

自動(dòng)擴(kuò)縮容主要來自HPA（Horizontal Pod Autoscaler）控制器，而本文主要實(shí)現(xiàn)基于CPU使用率進(jìn)行Pod擴(kuò)縮容的功能。HPA控制器基于K8s master節(jié)點(diǎn)中的kube-contorll-manager服務(wù)啟動(dòng)參數(shù)和其中相關(guān)參數(shù)定義的探測(cè)周期，該周期默認(rèn)為15秒，插件是系統(tǒng)在這個(gè)15秒的周期內(nèi)不停地監(jiān)測(cè)目標(biāo)Pod的相關(guān)具體指標(biāo)，得到指標(biāo)后，再通過與HPA設(shè)置的擴(kuò)縮容條件進(jìn)行對(duì)比，如果滿足條件，則系統(tǒng)會(huì)快速自動(dòng)調(diào)整相應(yīng)的Pod。

HPA工作原理：

本次畢業(yè)設(shè)計(jì)主要采用了Metrics-Server，該插件會(huì)持續(xù)采集所有Pod的指標(biāo)數(shù)據(jù)，HPA控制器獲取這些數(shù)據(jù)后，使用用戶定義的擴(kuò)縮容規(guī)則進(jìn)行計(jì)算，得到目標(biāo)Pod副本數(shù)量。當(dāng)目標(biāo)Pod副本數(shù)量與當(dāng)前副本數(shù)量不同時(shí)，HPA控制器訪問Pod的副本控制器發(fā)起scale操作，調(diào)整相應(yīng)的Pod的副本數(shù)量，完成擴(kuò)縮容操作。

控制器在得到Pod性能指標(biāo)數(shù)據(jù)后，將計(jì)算出的Pod數(shù)量與當(dāng)前數(shù)量相對(duì)比，具體算法公式如下：

[desiredReplicas=ceilcurrentReplicas*curentMetricValuedesiredMetricValue]? （1）

結(jié)果向上取整。

異常情況如：

1）Pod正在被刪除;

2）Pod當(dāng)前指標(biāo)未被獲得;

3）若指標(biāo)值為CPU利用率，則對(duì)于Ready狀態(tài)的Pod不納入指標(biāo)。

HPA控制器在進(jìn)行擴(kuò)縮容時(shí)，系統(tǒng)會(huì)記錄信息，控制器會(huì)選取得分最高的建議，讓整個(gè)系統(tǒng)在縮容時(shí)更平滑，消除短時(shí)間內(nèi)指標(biāo)值快速波動(dòng)的影響。除此之外，HPA還可以基于自定義指標(biāo)進(jìn)行自動(dòng)擴(kuò)縮容。需要使用Prometheus Adapter，Prometheus 用于監(jiān)控應(yīng)用的負(fù)載和集群本身的各種指標(biāo)，Prometheus Adapter可以幫我們使用 Prometheus 收集的指標(biāo)使用它們制定擴(kuò)展策略，這些指標(biāo)都是通過 APIServer 暴露的，而且 HPA 資源對(duì)象也可以直接使用。

4系統(tǒng)測(cè)試

本次主要通過CPU的利用率為指標(biāo)進(jìn)行自動(dòng)擴(kuò)縮容。想要實(shí)現(xiàn)Pod副本數(shù)量擴(kuò)縮容，就必須使HPA控制器可以查看節(jié)點(diǎn)資源使用情況。7ABD40FB-A7EB-4270-A803-81E2C2F84682

輸入命令：kubectl top node

輸入命令：kubectl run php-apache --image=mirrorgooglecontainers/hpa-example --requests=cpu=200m --expose --port=80運(yùn)行hpa-example，請(qǐng)求CPU的資源為200m，暴露一個(gè)80端口。

輸入命令：kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10

當(dāng)deployment資源對(duì)象的CPU使用率達(dá)到50%時(shí)，就進(jìn)行擴(kuò)容，最多可以擴(kuò)容到10個(gè)。

以上便生成了一個(gè)HPA控制器，可以用作自動(dòng)擴(kuò)縮容。

在K8s node1節(jié)點(diǎn)上，通過對(duì)于Pod進(jìn)行死循環(huán)請(qǐng)求，同時(shí)請(qǐng)求可以得到：

如圖4示;說明循環(huán)請(qǐng)求已經(jīng)成功

查看Pod數(shù)量是否變化

while true; do wget -q -O- 10.99.60.48; done

如圖5所示，創(chuàng)建其余的Pod并分配至其他節(jié)點(diǎn)，停止死循環(huán)請(qǐng)求一段時(shí)間后，發(fā)現(xiàn)Pod 數(shù)量回歸至一個(gè)。

由圖6可知，通過HPA可以將K8s中的Pod以CPU利用率為指標(biāo)進(jìn)行自動(dòng)擴(kuò)縮容。

在自動(dòng)擴(kuò)縮容中，通過metri-server獲得CPU的利用率，內(nèi)存利用率、硬盤讀寫等一系列指標(biāo)由于無法衡量，所以通過CPU利用率，利用HPA將利用率過高的K8s node2節(jié)點(diǎn)中的相關(guān)請(qǐng)求Pod，通過復(fù)制調(diào)度部署到其他節(jié)點(diǎn)上，從而確保5G核心網(wǎng)的準(zhǔn)確運(yùn)行。

5結(jié)論

本文主要通過搭建Docker環(huán)境，通過Kubernetes在不同主機(jī)的管控下，利用虛擬機(jī)中Ubuntu18.4系統(tǒng)為主要環(huán)境，并在該環(huán)境上部署5G核心網(wǎng)元，并為每個(gè)網(wǎng)元通過分配IP和端口號(hào)外，接入基站測(cè)試，以實(shí)現(xiàn)簡易的云原生5G核心網(wǎng)系統(tǒng)。構(gòu)建5G核心網(wǎng)成功之后，通過研究K8s自帶的負(fù)載均衡算法：四層負(fù)載均衡和七層負(fù)載均衡實(shí)現(xiàn)簡易的負(fù)載均衡網(wǎng)元Pod擴(kuò)展，實(shí)現(xiàn)5G核心網(wǎng)的基本功能，通過研究K8s的手動(dòng)擴(kuò)縮容和自動(dòng)擴(kuò)縮容，通過對(duì)于節(jié)點(diǎn)的禁止使用，實(shí)現(xiàn)K8s對(duì)于Pod的節(jié)點(diǎn)間轉(zhuǎn)移，驗(yàn)證K8s對(duì)于5G核心網(wǎng)正常工作的保障。

參考文獻(xiàn)：

[1] 黃震寧，李愛華，張昊，等.3GPP R16 5G核心網(wǎng)技術(shù)綜述[J].移動(dòng)通信，2021，45（1）：85-89.

[2] 張藝鑫.5G通信技術(shù)應(yīng)用場(chǎng)景與關(guān)鍵技術(shù)[J].信息記錄材料，2020，21（12）：182-183.

[3] 楊文強(qiáng)，王友祥，唐雄燕，等.面向云原生的5G核心網(wǎng)云化架構(gòu)和演進(jìn)策略[J].郵電設(shè)計(jì)技術(shù)，2021（3）：12-15.

[4] 賽迪智庫無線電管理研究所. 5G發(fā)展展望白皮書（2021）[N].中國計(jì)算機(jī)報(bào)，2021-03-01（8）.

[5] 蒲澤宇.5G核心網(wǎng)AMF虛擬化及負(fù)載均衡平臺(tái)設(shè)計(jì)與實(shí)現(xiàn)[D].北京：北京郵電大學(xué)，2020.

[6] 陳長怡，陸鋼，周麗莎，等.基于云原生的輕量級(jí)5GC產(chǎn)品及關(guān)鍵技術(shù)[J].電信科學(xué)，2020，36（12）：89-95.

【通聯(lián)編輯：唐一東】7ABD40FB-A7EB-4270-A803-81E2C2F84682