C114讯 1月23日消息（艾斯）来自市场研究公司Omdia的最新报告写到，对于电信业来说，采用云原生架构具有多重重要的考量因素和影响。正如下一代移动网络联盟（NGMN）所阐释的，云原生并不仅仅是将工作负载容器化：它实际上改变了电信运营商的运营环境。

传统上，电信运营商依赖网络设备供应商来构建和部署其网络功能。这种依赖供应商的模式使其未能充分准备好应对云原生转型带来的复杂性和运营挑战。至关重要的是，电信运营商需要合适的工具来应对这些变化。

Omdia资深分析师Inderpreet Kaur在这篇文章中重点介绍了思博伦的Landslide测试套件如何简化电信运营商的云迁移之旅。

电信网络正向云基础设施迁移

据Omdia估计，2024年全球电信运营商在网络功能云化方面的支出约为157亿美元。这占电信运营商网络基础设施设备资本支出的23%，约占移动网络和固网行业总资本支出的5%。

Omdia预测，电信网络云市场将从2025年的174亿美元增长至2030年的248亿美元，复合年增长率为7.3%。如图1所示，Omdia预计在整个预测期内将保持中高个位数的增长。

图1：电信网络云市场到2030年将达到248亿美元，资料来源：Omdia。

Omdia估计，电信运营商在网络云方面的支出在2025年将增长12%，是2024年6%增长率的两倍。电信运营商对5G核心网、IMS以及无线接入网（RAN）基础设施现代化改造持续表现出浓厚兴趣。运营商在更新现有供应商合同时，正倾向于选择云原生部署。

云原生迁移面临诸多挑战

云原生与5G核心网设计原则使电信运营商能够选择模块化和分解式架构，从而更好地实现网络功能软件与硬件平台之间的解耦。虽然这种解耦使得水平云技术供应商（如Red Hat、SUSE、博通旗下VMware、Wind River）更容易参与进来，但也引入了新的运营挑战。电信运营商在网络转型过程中必须克服诸多障碍。

·解决应用性能与可靠性问题

云原生网络功能（CNF）必须满足3GPP规范要求的安全、弹性及性能标准，并达到与基于专用设备的网络功能同等的水平。与传统设备不同，云原生部署涉及多供应商系统，其中CNF、容器即服务（CaaS）以及云基础设施由不同供应商提供。在垂直解决方案中，网络功能供应商负责评估应用（CNF、虚拟网络功能/VNF）的性能与可靠性。这在多供应商系统中很难实现。

此外，CNF利用微服务架构，将网络功能的各种功能分解并分发为独立的微服务，每个服务通常作为一个或多个容器实现，并分组到Kubernetes Pod中。Pod是Kubernetes实现中的基本调度单元。Kubernetes将每个容器置于一个Pod中，这一Pod作为该容器的上下文，拥有其独立的命名空间、存储卷和配置数据。

理论上，这种微服务架构使CNF在应对故障时更具弹性，因为修复问题只需处理单个或一组受影响的服务进程/Pod，而无需重启或调试整个应用。然而，这种优势的代价是复杂性的增加，因为系统现在必须理解映射到多个微服务的CNF分解结构，其中包含大量交互和隐藏的依赖关系。精确定位导致性能下降的具体Pod成为一项复杂的任务。

CNF的可靠性与弹性相关，即自动修复故障Pod的能力。一个关键挑战在于确保每个CNF的设计和构建都能提供所需的弹性。目前，并非所有CNF都基于云原生原则设计；许多仍是单体式架构，只是将相同的VNF代码封装在容器包装器中而非虚拟机中交付。因此，运营商根据这些要求评估CNF的就绪度变得至关重要。

·确保云资源高效利用

分析师Inderpreet Kaur指出，对于部署云原生网络的电信运营商而言，云资源（计算、存储和网络）利用率低下是一个关键挑战。造成这种情况的原因有多个方面。随着网络功能从物理网络功能（PNF）迁移至VNF和CNF，供应商仍倾向于按峰值容量配置硬件基础设施。即使对于水平云架构，运营商也会为不同的CNF设置独立或隔离的环境，并为这些环境预留峰值容量资源。这种架构虽然更容易实现，但会导致计算、存储和内存资源利用率严重不足。

英国老牌运营商英国电信（BT）在接受Omdia采访时承认，其水平基础设施即服务基础设施（IaaS）仍存在这个问题。BT解释说，CaaS与CNF的紧密捆绑使其无法对基础设施资源进行精细化控制。此外还存在一些其他问题。BT表示，很多时候，CNF供应商会对底层云基础设施提出特定要求，以确保应用弹性。供应商还会设置Pod的亲和性与反亲和性要求，这限制了可调度特定Pod的节点。

·使组织结构适应运营模式

正如德国电信（DT）向Omdia所解释的那样，从垂直孤岛向水平层级转变伴随着其团队的重组。该运营商为基础设施、自动化及工作负载设立了独立的团队，并辅以敏捷规划周期。运营团队负责设计、构建和维护云基础设施。该团队将云资源作为租户工作负载提供给应用所有者，应用所有者则负责CNF和VNF的生命周期管理。

为了实施精益运营，DT建立了统一的自动化框架。DT部署了一个通用的CI/CD流水线，以简化云基础设施与应用所有者之间的工作流程。它利用DevOps框架，并结合持续测试和验证，来实现其云原生网络的部署和升级。

此外，将各种组件整合到云堆栈中的所有权也发生了变化。在DT的案例中，运营商承担了这项责任。对于许多小型网络运营商而言，这是一个关键的制约因素。他们通常缺乏支持此类转型所需的技能、组织结构、思维方式、工具和人力资源。

思博伦如何应对云原生网络测试挑战

网络功能与底层云基础设施的解耦带来了额外的挑战，需要验证CNF在云基础设施上的合规性、安全性及性能。思博伦Landslide平台通过其5G CNF弹性验证和云原生基础设施基准测试套件，简化了运营商的云原生部署。

思博伦（现为是德科技Keysight旗下公司）最近扩展了Landslide平台的能力，以提供全面的云原生基础设施基准测试。这些框架有助于确保CNF在运营商现网中交付所需的关键绩效指标（KPI）。

如图2所示，弹性框架旨在提高应用的性能和可靠性。它帮助电信运营商评估CNF是否具有弹性设计——在实时环境中是否能够自我修复和自动扩展。运营商可在以下场景中运行CNF弹性测试用例：

·对象故障：指容器、Pod或节点发生故障或崩溃。

·网络拥塞：指因丢包、网络带宽降低等网络问题导致CNF无法交付所需KPI。

·资源限制：涉及云资源使用率或CPU、内存、网络资源的可用性。

图2：思博伦Landslide云原生测试套件。资料来源：思博伦，现为是德科技旗下公司。

云基础设施基准测试用例旨在发现CNF是否能够高效利用云资源。它帮助电信运营商理解CNF供应商对资源扩展和工作负载迁移所设定的依赖要求。

分析师Inderpreet Kaur写到，电信云基础设施团队通常缺乏对服务KPI以及实现这些KPI所需最优资源的可见性。思博伦的云基础设施测试用例使基础设施团队能够根据定义用户体验质量的KPI（如延迟、丢包和抖动等），对计算、存储和网络资源进行基准测试。这些详细信息有助于云基础设施团队合理调整CNF实例的规模。电信团队可以更有信心地在在管理性能挑战的同时避免云资源的过度配置。

Omdia指出，思博伦Landslide测试套件的一个关键亮点是其测试用例在电信运营商CI/CD/CT流水线中的可重复性与可集成性。据思博伦介绍，测试场景可在多个云环境和硬件基础设施中复制。此功能在规划和实施硬件升级/更换周期时非常有用。随着CNF和CaaS升级变得越来越频繁，电信运营商可以衡量这种升级对资源总体利用率的影响。