Kubernetes 中的实时媒体：媒体流网格

媒体流网格使实时媒体应用成为云原生 Kubernetes 环境中的一等公民。它的目的是将基于 HTTP 的网络应用的服务网格所带来的可操作性、可观察性和安全性的特点带到基于 RTP 的实时媒体应用。在这个演讲中，我们将介绍媒体流网格的最新情况，并将展示一个现场演示。

来源：FOSDEM 2023
题目：Media Streaming Mesh, Real-Time Media in Kubernetes
主讲人：Giles Heron
原文地址：https://fosdem.org/2023/schedule/event/media_streaming_mesh/
内容整理：李江龙——煤矿工厂

为什么是媒体流网格（Media Streaming Mesh）

看到 Kubernetes，我的主要印象它对 Web 应用非常支持。但是我们将怎样做实时媒体？我认为，你可以用两个矩阵将世界一分为二，应用程序有实时的和非实时的，有互动应用程序和流媒体应用程序。

Kubernetes 就在矩阵的左上角，这一切都是关于网络应用的。那么我们怎么做实时应用程序呢？这就是我们项目所关注的。最初我们关注的是任何实时的东西，包括可能是股票交易或任何东西的在线游戏。后来就焦点而言，我们决定专注于实时媒体和任何基于 RTP 的东西。所以它可以是 Web RTC，但同样它可以是 RTSP，它可以是实时视频，诸如此类。

我们将如何在 kubernetes 中支持这一点？目前 kubernetes 中的一个重要功能是服务网格（service meshes）。服务网格所做的是在每个 Pod 处终止您的 TCP 连接，因此，您不是在您的群集(Kubernetes 群集)之间进行路由，而是通过 Web 代理进行访问。所以你得到了安全性和良好的统计数据，这类事情是以复杂性为代价的。这些服务面临的挑战是，它们将适用于 TCP 应用程序。它们对 HTTP 应用程序也非常有用，因为你可以进入并进行 URL 路由。但它们不支持 UDP，他们当然也不支持实时媒体应用程序。

如果使用 kube-proxy 和节点端口，就是 Kubernetes 使用的标准 NAT。因此，Kubernetes 通常所做的就是提供永久 IP 地址之类的服务。与依赖显然可以缓存内容的 DNS 不同，您可以将永久 IP 地址放在服务上，然后您就可以获得支持该服务的各个 Pod 的临时 IP 地址。这些服务对基本服务再次有效（在上图中用黄色表示），但当您从群集外部公开事物时，通常会在节点端口中使用这些高端口号，这非常混乱。并且它们不支持实时媒体。但是如果您正在做像 SIP 和 RCSP 这样的事情，通常会看到将会有一个要协商的 TCP 通道。它可以是 TCP 可以是 UDP，但它会协商媒体端口。因此存在的挑战是，媒体端口协商对媒体来说是完全看不见的。所以如果您尝试以这种方式部署它，它将会崩溃。

有些人把会议解决方案部署到 kubernetes 上，他们将使用主机网络。这样把所有内容都放在主机名和空格中，没有 NAT。您只能在每个节点上放置一个 Media Pod，因为如果您希望有多个 Media Pod 都公开同一端口，那么您在主机上只有该端口的一个实例，这没有问题。但如果您要在 VMS 上运行，则需要调整您的 VMS 的大小，使之适合一个 Media Pod。而且在您的集群中拥有更多节点也是有代价的。但如果您要部署到裸机上，那会很糟糕的。

我们提出的媒体流网格表示让我们关注这个实时媒体，让我们支持每个节点的多个媒体部分，我们也可以直接或与服务网格结合来支持其他服务。

媒体流网格的优点

1. 可观察性

媒体流网络监控整个网络的抖动和数据包丢失，使 DevOps 团队能够快速定位和解决连接问题。

2. 安全性

媒体流网格使用 SPIFFE/SPIRE 对流量发送者进行认证，并可使用 SRTP 对流量进行加密。代理机构减少攻击面并确保协议的一致性。

3. 低延迟

媒体流网格 RTP 数据平面代理增加了最小的延迟，与在每一跳终止 TCP 连接的网络代理形成鲜明对比。

4. 可部署性

轻量级的每节点数据平面代理，和每集群控制平面代理确保了比每节点网络代理更低的占用率，使其适合部署在边缘。

软件架构

我们有一大堆组件，我们试图说的是将其分解为我们在 kubernetes 中放置什么。因此每个集群运行一个服务，每个节点运行一个 daemonsets，然后你可以在应用程序 Pod 中运行一些东西。我们在 Pod 的 yaml 文件上有一个注释，上面写明这是我们的一个 pod，因此发射 Webhook 将拦截它。当 pod 被实例化时，它将在 Pod 和 APP 中包含我们的存根。实际上我们在网络开发室插入了一个 chain c, 它所做的就是添加我们将要使用的 IP 表或 EF 规则重定向该控制平面流量。

我们想为每个集群构建一个控制平面以最大限度减少占用空间。今天基本上是把 kuberes 的 API 和核心 DNS 都调出来了。如果你正在连接一个 URL，我们想找出哪些活动运行的 Pod 支持那个 URL，这就是那件部件的作用。有效地从您的应用程序中保存您的 RTSP 会话。存根拦截该 TCP 连接，它使用 gRPC 来泵送数据消息或 RTSP 控制平面的实际有效负载，进入我们的控制平面，然后被我们使用。我们用 Go 语言对代理进行编程，我们只会在 Go 语言中寻找我们可以插入的现有库。

我的感觉是，我们实际上在做两件不同的事情。一是我们有这种动态协议，无论是 RTSP 还是 SIP。但另一方面，我们知道如何将这些东西映射到 kubernetes 中。试想一个逻辑图，我们有一个流的发送者和接收者，我们想要做的是分解它并说出它如何在 kubernetes 上映射，哪些接收者在哪些节点上，那么我们如何构建应用层多播的树呢？我认为理想情况下我们希望将这两者分开，这样控制平面就会有我们为 RTSP 或 SIP 或其他任何东西插入的插件，然后控制器会负责将其映射到 kubernetes。

存根之所以叫存根，因为它太小了。所以我们用 Rust 编写了这个，使用一些方法来保持低内存占用并且它避免了任何延迟峰值。我们认为如果开始进行垃圾积累，那将是一个问题。但我不想在 2023 年用 C 语言写，在某些情况下，存根是可以控制的。它负责控制平面，但在某些情况下，它也会拦截数据平面。RTSP 就是一个例子，有一个选项可以在一个 TCP 套接字上传输所有内容。因此，我们所能做的是捕获所有流量，然后通过我们的网络用 UDP 发送，这样我们就可以执行所有复制和所有操作。但也可能有其他情况，例如，你想要在 Pod 上进行监控。对于电视类型的东西，你想从边缘做实时视频复制，因为你不希望有任何共享的堆栈。

项目的挑战和号召

为了在这个项目中取得成功，我们需要的是让人们更容易做出贡献，而不只是基于代码的贡献。我认为真正的成功关键是推动一个过滤器生态系统，在那里人们可以贡献自己的过滤器。比如谷歌的 Quilkin，作为游戏的代理，我注意到修改它的唯一方法是真正进入代码中。我不希望人们不得不进入这里的代码，我希望有一个非常简单的 API。代理过滤器的框架将具有过滤器链，无论报文头是什么，都可以直接使用。我们剥离所有报文头，然后我们只需将其分别通过一个过滤器链。过滤器链的每个部分都发挥着自己的作用，关键挑战将是我们如何使其规模化运行。

我们的目标是可以真正在 Kubernetes 中部署实时媒体应用程序，并使其发挥作用，目前效果并不理想，这是一项正在进行的开源工作。我认为更多的人会帮助我们更快地完成这项工作。如果我们得到正确的架构，那么就有希望让人们更容易做出贡献，这样我们就有希望扩大规模。请加入我们的项目。

项目主页：https://www.mediastreamingmesh.io/

Github：https://github.com/media-streaming-mesh

问答环节

Q: “这个项目的质量如何”

在这一点上，我们目前正在与 Cisco 的另一个团队进行一些集成工作，他们希望将其用于某些事情。我猜测 RTSP 是我们清除 BUG 的所在，我们真的希望有人能贡献其他协议。

Q: “与其他开源项目的集成方式是什么样的”

对于其他开源项目，我认为就其集成方式而言，我想这取决于该项目及其适合度，因为我们已经很大程度上分离控制平面和数据平面。所以如果其他项目也这样做了，那么我想我们可以把控制平面插入我们正在做的事情。目前来说其他项目必须是用 Go 语言写的，因为我们的控制平面用的是这种语言。做到了以上，接入我们数据平面的 API 还要足够干净，才能和其他模型集成。如果它不成功，就把整个东西作为一个博客贡献出来。