借助Service Proxy for Kubernetes增强电信运营商5G网络架构

F5生态系统 | 2022年8月22日

2018年初，我经常与精通网络和新兴5G标准的朋友及同事进行类似的交流。我们都隐约感到不安，因为整个行业正匆忙迈向一场充满大量未知因素的转型。我们都明白，5G将推动行业向容器和云原生架构转型，但也知道，Kubernetes和其他云原生工具最初是针对一套完全不同的用例而创建的。我们都看到（相信许多阅读本文的人也有所察觉），整个行业正走向一场令人头疼的冲突。

自那些令人忧虑的日子以来，通信服务提供商（CSP）已开始切实推进向云原生基础设施的迁移。率先开展此类部署的企业确实发现了一些意料之外的障碍：Kubernetes最初设计的网络功能在一些关键领域无法满足服务提供商用例的需求。无论电信运营商的目标是部署5G独立组网（SA）核心网，还是实施采用分布式云架构的现代化计划，都需要调整Kubernetes，使其支持网络互操作性、电信级规模和运营商安全策略。这些都是整个云原生基础设施所需的关键能力。

由于Kubernetes此后的演进主要侧重于在公有云或企业环境中运行的Web和IT用例，因此其最初并未考虑部署服务提供商用例所需的一系列独特要求和协议，这一点不难理解。不过，Kubernetes的架构师采用了一套可靠的设计模式，使Kubernetes具备可扩展性，从而为电信行业的基础用例提供了实现路径，包括网络流量管理、可见性与控制，以及对HTTP/2、GTP、SIP和Diameter等协议的扩展支持。

在说明需要进行哪些增强才能使Kubernetes适用于当今的服务提供商用例之前，我们先来明确服务提供商网络带来的独特要求。

Kubernetes必须融入更大的生态系统

首先，Kubernetes集群必须与服务提供商更广泛的网络和运营体系集成。架构决策可能产生长期影响，包括增加运营成本和复杂性。网络架构师必须考虑多种电信应用场景、对传统协议的支持，以及Kubernetes内部的动态变化可能如何影响现有网络拓扑，进而可能增加复杂性。

其次，电信工作负载（网络功能）不同于IT工作负载。服务提供商网络及其网络功能使用的不仅是标准HTTP/HTTPS或TCP。对移动通信服务提供商而言，网络必须同时支持SIP、GTP、SCTP等传统3G/4G协议以及5G HTTP2，这一点至关重要。与IT工作负载相比，电信工作负载还需要在传统网络层之上遵循额外一层标准。

最后同样重要的是，面对所有新的暴露点，安全至关重要，因此需要新的自动化、可视性和管理功能。引入新技术时，必须在各层部署安全措施，并与新集群协同工作。服务提供商的安全运营团队始终在探索如何缩小攻击面并实施一致的安全控制。此外，还需要更新更广泛的网络安全策略，使其能够随时间推移灵活调整。

当前弥补这些功能缺口的两种方法

绕过Kubernetes模式

规避云原生模式表明，由于Kubernetes本身并未提供处理电信工作负载所需的工具，架构师不得不采用变通方案。我们观察到，电信运营商正以几种令人担忧的方式打破这些模式：

绕过Kubernetes网络：绝大多数CNF都将一个或多个接口置于Kubernetes的控制范围之外。这些CNF需要直接访问网络（通常以请求使用“multus”的形式提出，以便增加一个直接连接外部的接口）。由于缺少统一的网络控制点，Kubernetes内部的复杂性会暴露给外部服务提供商网络，导致运维复杂性和成本增加，安全攻击面也随之扩大。此外，应用或网络功能开发人员及网络运营商还需承担更多工作，包括管理IP地址，以及应对Kubernetes中容器的动态特性，而这些特性如今也暴露给了外部环境。
为每个网络功能使用独立集群：Kubernetes网络原生不提供统一管理网络流量入口和出口的中心节点。Kubernetes虽提供一定的入口控制，但几乎完全忽略出口流量，也没有内置方式将入口和出口网络关联起来。我们发现，在多个部署中，每个网络功能都在各自的集群中运行，以便将服务器IP地址与网络功能IP地址关联起来。这会增加资源开销和资本支出，同时也会增加运维复杂性，进而提高运营支出。

遵循Kubernetes模式

另一种方法是遵循Kubernetes设计模式，并引入服务代理，为Kubernetes集群面向外部环境的入站和出站网络及安全提供“统一管理界面”。服务代理旨在弥补Kubernetes用于服务提供商环境时存在的功能缺口。服务代理应：

使用 Kubernetes 原生模式扩展 Kubernetes 网络功能（自定义资源定义、K8s 控制循环）
与更广泛的网络互联（BGP路由、出口SNAT IP分配、IPv4/v6转换）
关联入站和出站流量，分别针对每个CNF
提供广泛的L4/L7支持（tcp、udp、sctp、NGAP、HTTP/2、Diameter、GTP、SIP）
提供安全层（TLS终止、网络防火墙、DDoS防护、Web应用防火墙）
呈现一致的CNF，隐藏高度动态的Kubernetes事件

F5的方法：引入服务代理

F5选择了上述第二种方案，通过扩展Kubernetes并创建此服务代理来补充这一缺失功能。凭借数十年的流量管理和安全专业经验，我们认为，这是支持大规模云原生迁移所需的一项关键功能。为直接解决Kubernetes的不足，并让服务提供商能够创建原生Kubernetes所不具备的资源，我们开发了云原生基础设施产品BIG-IP Next Service Proxy for Kubernetes（SPK）。该产品已达到生产就绪状态，现已推出。SPK通过一个可实现自动化并与更广泛的网络和安全策略顺畅集成的框架，简化架构并增强其安全性。这种面向电信运营商的Kubernetes方案将继续降低复杂性和运营成本，同时提高基础设施的韧性和安全性。当前，向5G SA迁移的进程正在放缓（GlobalData发现，电信运营商未能顺利部署5G SA）。可以合理推断，如果不引入合适的服务代理，迁移进程将进一步受阻。正在开展大规模数字化现代化改造的电信运营商客户已在生产环境中使用SPK，并发现SPK正逐步证明，它能够解决5G网络架构中一个此前未被察觉的Kubernetes相关问题。