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进行一系列的转发操作。
nlc202207151144
转载注明来源:https://www.xzbu.com/8/view-15435991.htm
