基于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 核心网系统拥有初步的负载均衡和扩缩容能力。