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 还要足够干净,才能和其他模型集成。如果它不成功,就把整个东西作为一个博客贡献出来。

版权声明:本文内容转自互联网,本文观点仅代表作者本人。本站仅提供信息存储空间服务,所有权归原作者所有。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至1393616908@qq.com 举报,一经查实,本站将立刻删除。

(0)

相关推荐

发表回复

登录后才能评论