如何在 Kubernetes 中部署实时应用程序

实时应用程序的运行非常困难，需要大量的工作和资源。如果你曾经尝试过部署实时应用程序，你就会明白我在说什么。你必须面对 NAT、防火墙、可扩展性、维护以及出现的任何异常情况。不过，有了 Kubernetes，你可以减少或至少改变这些问题。本文将向你展示在 Kubernetes 中部署实时应用的两种方法。

RTC 和 Kubernetes

WebRTC 是一种允许两个或多个设备通过互联网进行实时通信的技术。它非常适用于视频通话、语音聊天和游戏服务器，但使用案例的数量要大得多。

RTC 在很大程度上依赖于媒体服务器为用户提供出色的功能，例如

信令
中继
转码
录音
分析

媒体服务器通常暴露在公共互联网上，因此容易受到许多安全风险的影响。媒体服务器最常见的安全风险包括

拒绝服务 (DoS) 攻击
中间人攻击
数据泄露

除此之外，媒体服务器还有其他问题，例如

难以扩展：大多数情况下，你无法独立操作多个媒体服务器。你必须了解整个拓扑结构。
可靠性差：如果你的服务器宕机或受到攻击，那么你的客户端就会出现连接问题。
管理有问题：在没有自动化的情况下配置多个媒体服务器，总会有配置错误的可能。
成本：服务器的价格可能很高。

Kubernetes 可为媒体服务器的部署提供安全、可扩展的环境，从而帮助降低这些风险。

Kubernetes 是一个开源容器编排系统，可自动部署、扩展和管理容器化应用程序。它提供了一种在多台主机上大规模运行和管理容器化应用程序的方法。

在 Kubernetes 中放置媒体服务器主要有两种方法：

hostNetwork 方法：这种简单但有风险的解决方案是从 Kubernetes 节点创建一个 “常规 “服务器。这意味着每个人都能看到公共节点的 IP，而且 pod 可以打开节点上的任何端口。而且，这种解决方案无法提供 Kubernetes 的全部操作和维护功能。此外，使用 hostNetwork 方法，如果要扩展部署，就必须扩展节点数量。

使用 STUNner： STUNner 是一个 Kubernetes 网关，可以处理 STUN/TURN 流量。这种方法不需要使用 hostNetwork，因此不必暴露所有端口。它还能让操作和维护变得更容易。与使用 hostNetwork 不同的是，在这里您不必为扩展部署而强制扩展节点。

hostNetwork 方法

hostNetwork 参数能让 pod 直接访问主机的根网络命名空间。这意味着你的 pod 无需 Kubernetes 服务即可可见。有了这个参数，pod 本身就可以打开主机网络上的任何端口。你可以感觉到，这带来了很多顾虑……

使用 hostNetwork 有几个缺点：

安全性：启用 hostNetwork 的 Pod 可以完全访问主机网络，这可能会带来安全风险。
可扩展性：启用 hostNetwork 的 Pod 无法在同一节点内扩展。试想一下，如果同一网络中的两个 Pod 试图打开同一个端口……

不过，使用 hostNetwork pod 类似于使用 “普通 “服务器作为媒体服务器，但你也从 Kubernetes 中获得了一些好处。事实上，这种方法只是解决了部分问题：

提高了可靠性。
部分解决了扩展问题。你无法在同一节点内扩展媒体服务器 pod，但可以自动扩展节点数量。
降低管理成本。
由于可以随时缩减到一个节点，从而降低了成本。

使用 STUNner

STUNner 允许您将任何 WebRTC 服务部署到 Kubernetes 中，将其顺利集成到云原生生态系统中。STUNner 为客户端提供符合标准的 STUN/TURN 网关，以便访问在 Kubernetes 中运行的虚拟化 WebRTC 基础架构，同时保持浏览器的完全兼容性，并且只需对现有 WebRTC 代码库进行少量修改，甚至无需修改。STUNner 实现了标准的 Kubernetes 网关 API，因此您可以通过 Kubernetes 清单以熟悉的 YAML 工程风格进行配置。

使用 STUNner 的好处：

在两个外部 UDP/TCP 端口上公开 WebRTC 媒体服务器。使用 STUNner，WebRTC 部署只需两个面向公众的端口、一个用于应用服务器的 HTTPS 端口和一个用于所有媒体的 UDP/TCP 端口。
无需依赖外部服务进行 NAT 穿越。STUNner 可以与 WebRTC 基础架构的其他部分部署在同一个集群中，任何 WebRTC 客户端都可以直接连接到它，除了 STUNner 本身之外，无需使用任何外部 STUN/TURN 服务。
轻松扩展 WebRTC 基础架构。STUNner 可让您将整个 WebRTC 基础架构部署到普通的 Kubernetes pod 中，因此扩展媒体平面就像发布 kubectl scale 命令或使用 Kubernetes 水平 pod autoscaler 一样简单。
安全的周边防御。无需在媒体服务器上打开成千上万个 UDP/TCP 端口以防止潜在的恶意访问；使用 STUNner，所有媒体都通过单一入口端口接收，您可以对其进行严格监控。

不过，与 hostNetwork 方法相比，STUNner 需要更多的 Kubernetes 知识。不过，只要一次设置正确，就不用再费心配置基础设施了。

结论

运行实时应用程序总是困难重重。您必须面对许多问题，如 NAT 穿越、可扩展性、可靠性和成本效益。Kubernetes 可为部署服务提供更安全、可扩展的环境，从而帮助缓解这些挑战。

只需将 hostNetwork 参数设置为 true，让应用程序使用根网络命名空间，就能在 Kubernetes 中部署实时应用程序。这样做很方便，但会带来安全风险，因为它允许黑客直接访问媒体服务器。此外，hostNetwork 的扩展性也不是最好的。你无法在同一节点内扩展部署。你必须扩展你的节点，而且扩展效率不如在一个节点内扩展。

使用 STUNner 是在 Kubernetes 中部署实时应用的更好方法。它比使用 hostNetwork 更安全，可扩展性更高。STUNner 就像第一道防线，它只在两个端口可见，因此你的部署可以在一个节点内扩展。

Kubernetes 是一个伟大的工具，它能帮助你实现操作工作的自动化，只要多做一点工作，你几乎可以用它来做任何事情。对于需要详细联网和资源管理的技术来说，这是个不错的选择。