5G云原生部署機制研究與仿真

陳梅 蘇晨 趙靜雅 高震宇

摘要：為推動目前現有開源5G核心網的進展，文章通過研究云原生5G核心網原型系統平臺的構建，以達到現有網絡功能的容器化實現。首先構建簡易的開源5G核心網，通過Kubernetes（簡稱K8s）自帶的四層負載均衡和七層負載均衡，驗證模擬多并發時系統的負載均衡能力及擴縮容能力;將核心網通過所搭建的核心網的NGAP口STCP口的地址進行連接，進行整個系統的調試，通過沖石通信模擬器通過設置UE數目，仿真基站進行整個系統的可靠性測試。進行負載均衡驗證，完成云化環境中的動態擴縮容算法的研究，以實現具備高可靠的云原生5G 核心網系統平臺。

關鍵詞：云原生;5G核心網;Kubernetes;動態擴縮容;負載均衡

中圖分類號：TP393? ? ? 文獻標識碼：A

文章編號：1009-3044（2022）15-0049-03

1 引言

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

2系統工作原理

該系統通過將5G核心網元部署到Docker上，之后通過K8s中的Pod將Docker中運行的核心網鏡像進行管控，對于5G核心網內部的工作原理由于過于冗長，且不是本文主要內容，所以不再進行解釋。如果對AMF、SMF、UDR、AUSF的請求過多，會通過K8s中的HPA自動擴縮容進行Pod的增加或者減少，同時如果哪個節點出現問題，通過K8s自帶的負載均衡算法也會將上面節點的Pod轉移至其他的節點，在這里用一個master、兩個node節點進行管控，通過將一個節點關閉調度，觀察其中的Pod轉移及新增Pod的情況。除此之外，通過一個新增的虛擬機對系統產生過多的激增請求，觀察K8s基于HPA對新增的Pod節點的調度。

2.1系統工作流程圖

2.2負載均衡

2.2.1四層負載均衡

使用IP+Port 接收，將其傳輸至相應的服務，并在傳輸層進行操作。客戶端和服務器進行一次TCP連接。該算法類似于路由器的作用。主要是在四層和七層起作用，而四層和七層的概念來自OSI七層模型。該算法主要是利用DNS解析，通過Kube-Proxy實現。該算法默認解析到虛擬IP是一個Service服務，該虛擬IP通過Kube-Proxy將其均衡到各個不同的Pod上。Pod的IP不穩定，每次重啟Pod后會隨機改變，但Service的IP是穩定的，所以主要是通過Node Port暴露服務，使相應的Pod可以被外界所訪問。Service根據Kube-Proxy不同的代理，展現出不同的性能。

1）User space模式

Service的請求會從用戶空間進入內核，然后再返回用戶空間，由 Kube-Proxy完成后端的選擇和代理工作，但這樣耗費的流量和資源十分巨大，導致性能急劇下降。需要注意的是：請求到達IPtables時會進入內核，而 Kube-Proxy主要作用是監聽用戶的工作狀態。因此請求會相應形成從用戶到內核再到用戶的一個傳遞過程， 從而降低了服務性能，因此，User space 性能差。

2）IPtables模式

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

這種四層負載均衡也有一些缺點，缺點如下：

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

Service的同時存在著很多分發策略：例如輪詢機制。將請求轉發到后端的各個Pod中，由此衍生出了加權輪詢，即給不同的Pod加入權重，幫助加速實現負載均衡。

2.2.2七層負載均衡

七層負載均衡主要來自現代通信的OSI七層模型中的第七層應用層，負載均衡器根據虛擬的URL和主機名接收或者發送請求，將請求進行相應的負載均衡處理后，進行相應轉發，最終實現整個系統的負載均衡。

七層負載均衡通過建立兩次TCP連接進行相應的負載均衡。客戶到負載均衡器，負載均衡器依據于相關的請求中所傳輸的內容主要來自URL或Cookie中的信息，選擇合適的負載均衡的算法，選擇相應的服務器;建立負載均衡器到服務器之間的連接。但必須注意的是負載均衡設備需要先實現服務器和客戶端建立TCP連接后，客戶端發送的含有應用層內容的報文會被接受，系統會根據該報文中的特定字段，通過負載均衡設備設置的服務器選擇方式，內部服務器會被最終確定，反向代理也由此而來。

Ingress 是K8s的一種資源對象，Ingress允許外部訪問K8s服務，通過創建規則集合配置訪問權限，這些規則定義了相應的服務被訪問的權限設置，支持 HTTP 和 HTTPS 協議;Ingress 配置相應的URL訪問設置、同時設立相關的主機名等一系列配置，促使系統正常運行。

七層負載均衡相較于四層負載均衡CPU占用率更高，但并不會導致服務器性能下降。七層負載均衡可以讓負載均衡器做出更恰當的反應抉擇，并通過相應操作對于相關內容進行優化，例如壓縮、加密等。七層負載均衡同樣可以利用buffering等一些操作卸載其他服務器的壞連接，從而提高性能。

Ingress-controller用來實現反向代理和負載均衡。

其主要作用方式為：通過監聽相應API對象里的配置規則，轉化成相應的配置，并對外部提供服務。

對于上述負載而言，還有若干種均衡算法：

第一種：輪詢均衡。負載均衡器將任何一次來自客戶端的請求輪流平均分配給其內部中的服務器，每次服務請求到達時，依次查找內部服務器，找到沒有負載的服務器，這種算法在服務器配置均衡的情況下，大有裨益。

第二種：權重輪詢均衡。由于每組組服務器中不同的服務器處理的性能有很大的差別，如果給每個服務器分配不同的權值，服務器可以因為不同的權值而規劃相應的負載。

第三種：隨機均衡（Random）。把來自網絡的請求通過哈希等相關算法不均勻地分配給內部中的多個服務器。

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

第五種：處理能力均衡。這種負載均衡算法是一種在七層負載下使用較多的均衡算法，該均衡算法的主要原理是依據相關的系統指標，將請求的服務分發給負載較輕的服務器，該指標包括服務器的處理性能和網絡的擁塞情況，所以更因地制宜、性能更優秀。

3自動擴縮容協調機制

擴縮容算法主要分為自動擴縮容和手動擴縮容，由于手動擴縮容依賴于命令直接禁止一個節點的調度，從而將pod分配至其他節點，沒有較多的內部原理，所以不再贅述，這里主要介紹基于HPA的自動擴縮容算法。

自動擴縮容協調：

自動擴縮容主要來自HPA（Horizontal Pod Autoscaler）控制器，而本文主要實現基于CPU使用率進行Pod擴縮容的功能。HPA控制器基于K8s master節點中的kube-contorll-manager服務啟動參數和其中相關參數定義的探測周期，該周期默認為15秒，插件是系統在這個15秒的周期內不停地監測目標Pod的相關具體指標，得到指標后，再通過與HPA設置的擴縮容條件進行對比，如果滿足條件，則系統會快速自動調整相應的Pod。

HPA工作原理：

本次畢業設計主要采用了Metrics-Server，該插件會持續采集所有Pod的指標數據，HPA控制器獲取這些數據后，使用用戶定義的擴縮容規則進行計算，得到目標Pod副本數量。當目標Pod副本數量與當前副本數量不同時，HPA控制器訪問Pod的副本控制器發起scale操作，調整相應的Pod的副本數量，完成擴縮容操作。

控制器在得到Pod性能指標數據后，將計算出的Pod數量與當前數量相對比，具體算法公式如下：

[desiredReplicas=ceilcurrentReplicas*curentMetricValuedesiredMetricValue]? （1）

結果向上取整。

異常情況如：

1）Pod正在被刪除;

2）Pod當前指標未被獲得;

3）若指標值為CPU利用率，則對于Ready狀態的Pod不納入指標。

HPA控制器在進行擴縮容時，系統會記錄信息，控制器會選取得分最高的建議，讓整個系統在縮容時更平滑，消除短時間內指標值快速波動的影響。除此之外，HPA還可以基于自定義指標進行自動擴縮容。需要使用Prometheus Adapter，Prometheus 用于監控應用的負載和集群本身的各種指標，Prometheus Adapter可以幫我們使用 Prometheus 收集的指標使用它們制定擴展策略，這些指標都是通過 APIServer 暴露的，而且 HPA 資源對象也可以直接使用。

4系統測試

本次主要通過CPU的利用率為指標進行自動擴縮容。想要實現Pod副本數量擴縮容，就必須使HPA控制器可以查看節點資源使用情況。7ABD40FB-A7EB-4270-A803-81E2C2F84682

輸入命令：kubectl top node

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

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

當deployment資源對象的CPU使用率達到50%時，就進行擴容，最多可以擴容到10個。

以上便生成了一個HPA控制器，可以用作自動擴縮容。

在K8s node1節點上，通過對于Pod進行死循環請求，同時請求可以得到：

如圖4示;說明循環請求已經成功

查看Pod數量是否變化

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

如圖5所示，創建其余的Pod并分配至其他節點，停止死循環請求一段時間后，發現Pod 數量回歸至一個。

由圖6可知，通過HPA可以將K8s中的Pod以CPU利用率為指標進行自動擴縮容。

在自動擴縮容中，通過metri-server獲得CPU的利用率，內存利用率、硬盤讀寫等一系列指標由于無法衡量，所以通過CPU利用率，利用HPA將利用率過高的K8s node2節點中的相關請求Pod，通過復制調度部署到其他節點上，從而確保5G核心網的準確運行。

5結論

本文主要通過搭建Docker環境，通過Kubernetes在不同主機的管控下，利用虛擬機中Ubuntu18.4系統為主要環境，并在該環境上部署5G核心網元，并為每個網元通過分配IP和端口號外，接入基站測試，以實現簡易的云原生5G核心網系統。構建5G核心網成功之后，通過研究K8s自帶的負載均衡算法：四層負載均衡和七層負載均衡實現簡易的負載均衡網元Pod擴展，實現5G核心網的基本功能，通過研究K8s的手動擴縮容和自動擴縮容，通過對于節點的禁止使用，實現K8s對于Pod的節點間轉移，驗證K8s對于5G核心網正常工作的保障。

參考文獻：

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

[2] 張藝鑫.5G通信技術應用場景與關鍵技術[J].信息記錄材料，2020，21（12）：182-183.

[3] 楊文強，王友祥，唐雄燕，等.面向云原生的5G核心網云化架構和演進策略[J].郵電設計技術，2021（3）：12-15.

[4] 賽迪智庫無線電管理研究所. 5G發展展望白皮書（2021）[N].中國計算機報，2021-03-01（8）.

[5] 蒲澤宇.5G核心網AMF虛擬化及負載均衡平臺設計與實現[D].北京：北京郵電大學，2020.

[6] 陳長怡，陸鋼，周麗莎，等.基于云原生的輕量級5GC產品及關鍵技術[J].電信科學，2020，36（12）：89-95.

【通聯編輯：唐一東】7ABD40FB-A7EB-4270-A803-81E2C2F84682