使用 Kubernetes 服务代理增强电信 5G 网络架构
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。 对于移动提供商来说，对传统 3G/4G 协议（例如 SIP、GTP、SCTP 等）和 5G HTTP2 的网络支持至关重要。 与 IT 工作负载相比，电信工作负载还具有位于传统网络层之上的额外标准层。
最后，当然也是最重要的一点，安全对于所有新的暴露点来说都是至关重要的，它们需要新的自动化、可视性和管理功能。 安全性必须部署在各个层面，并在引入新技术时与新集群协同工作。 服务提供商 SecOps 团队始终在寻找减少攻击面和实现一致的安全控制的方法。 此外，网络的更广泛的安全策略需要随着时间的推移进行更新和适应。
目前解决这些功能差距的两种方法
规避 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 并创建此服务代理来提供此缺失的功能。 基于我们数十年的流量管理和安全专业知识，我们相信这是支持大规模云原生迁移所需的关键功能。 我们开发了 BIG-IP Next Service Proxy for Kubernetes (SPK) 云原生基础设施产品，该产品已准备好投入生产并可供立即使用，旨在直接解决 Kubernetes 的缺点，并允许服务提供商创建“原始” Kubernetes 所缺乏的资源。 SPK 通过一个可自动化并与更广泛的网络和安全策略顺利集成的框架来简化和保护架构。 对于电信运营商来说，这种 Kubernetes 方法将继续降低复杂性和运营成本，并提供更具弹性和安全性的基础设施。 由于我们今天目睹了向 5G SA 过渡的放缓（ GlobalData 发现，电信运营商未能实现 5G SA ），可以安全地假设，如果没有引入合适的服务代理，过渡将进一步受阻。 处于大规模数字化现代化过程中的生产中的电信客户发现，SPK 被证明是 Kubernetes 解决方案，可以解决他们甚至不知道的 5G 网络架构问题。
