基于5G的微服務核心網部署及負載均衡算法研究

朱慶華，常瑩，張景峰

(北京電子科技職業學院電信工程學院，北京100176)

1 引言

5G核心網是第一個互聯網技術和通信技術融合(ICT)的實際應用，采用基于服務的網絡架構，其相較于4G，最主要的變化就是虛擬化，即網元功能虛擬化(NFV)，即使用HP，IBM等廠商的x86通用服務器，目前主要為刀片服務器[2]，而對于軟件而言，主要采用開源平臺，構建屬于自己的虛擬化平臺，將核心網網元在上面進行構建[3]。5G主要基于SBA架構，基于云原生設計，采取微服務理念[4]，將5G 核心網拆分為多個不同功能的個體，每個個體實現自己的微服務,使其具有高可用性[5]。云原生部署簡單快捷，應用按需伸縮，但依舊存在著安全性不足，可靠性不夠，需要研究負載均衡算法來應用多場景多業務的需求。

容器化技術可以輕松打包應用程序的代碼、配置和依賴關系，將其變成容易使用的構建塊，從而實現環境一致性、運營效率、開發人員生產力和版本控制等諸多目標。容器可以幫助保證應用程序快速、可靠、一致地部署人們所需的應用[6]，為5G核心網部署帶來便捷。

本文基于現目前開源5G核心網進展，研究云原生5G核心網原型系統平臺的構建，主要包括現有網絡功能的容器化實現，符合5G核心網的云原生系統構建，以及云化環境中的動態擴縮容算法的研究，以實現具備高可靠的云原生5G 核心網系統平臺。

2 系統工作原理及流程

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

3 負載均衡及擴縮容算法

3.1 四層負載均衡

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

Service 根據kube-proxy 的不同的代理，展現出不同的性能：

1)userspace模式

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

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)。

沖擊波波陣面前方A和后方B的應變、應力和粒子速度分別為和{εB, σB, vB} = {εB, σB, 0}，其中v為沖擊速度，其值在沖擊過程中逐漸減少。波陣面上的質量和能量守恒關系[13]分別給出：

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

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

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

3.2 七層負載均衡

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

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

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

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

圖2 七層負載均衡原理圖

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

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

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

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

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

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

4 負載均衡測試

四層負載均衡主要應用于單master 節點，即，通過關閉其中一個node節點，發現：停止一個節點的調度之后：

圖3所示，k8snode2節點停止調度

圖3 關閉節點調度

增加pod副本數驗證新增pod的節點分布

輸入命令：kubectl scale deploy/amf --replicas=5，將新增數設為5

由圖中可知，其新增節點均未在k8snode2上分布

恢復節點2(k8snode2)調度

輸入命令：kubectl uncordon k8snode2

輸入命令：kubectl get pods

圖4 重新調度后pod

可見原本的k8snode2節點上的pod，轉入k8snode2節點。

5 結論

本文通過四層負載均衡和七層負載均衡算法的介紹并通過但master節點，關閉一個節點之后，通過考察剩余pod所處節點位置得到service 和kube-proxy 將其中的pod 進行調度，實驗證明所得到所部署的基于k8s 的5G 核心網系統擁有初步的負載均衡和擴縮容能力。