MediaMTX 上 K8s零停机部署到生产集群的完整路径【免费下载链接】mediamtxReady-to-use Media-over-QUIC / SRT / WebRTC / RTSP / RTMP / LL-HLS / MPEG-TS / RTP live media server and media proxy that allows to read, publish, proxy, record and playback real-time video and audio streams.项目地址: https://gitcode.com/GitHub_Trending/me/mediamtx凌晨两点直播推流中断值班人员只能重启一整台虚机。如果流媒体服务本身就是一个无状态容器重启只需要几秒。MediaMTX 是一个零依赖的实时媒体服务器能把 RTSP/RTMP/HLS/WebRTC/SRT 等协议互相转换并转发我们部署它就是为了把重启一台机器变成替换一个 Pod。本文覆盖最小部署、生产配置和可观测性三块。项目能做什么 / 核心能力速览MediaMTX 把自己定位成media router流从一端进来按需转换协议后从另一端出去全程不落地转码所以延迟和 CPU 消耗都很低。几个关键能力全协议接入与互转推流支持 Media-over-QUIC、SRT、WebRTC、RTSP、RTMP、HLS、MPEG-TS、RTP拉流支持前六类同一路流可以同时被多种协议消费热重载配置修改配置文件后不踢掉已有客户端这是它能做零停机部署的前提录像与回放以 fMP4 或 MPEG-TS 分段落盘回放走独立的 playback 服务默认端口 9996认证体系内置用户、HTTP 回调、JWT 三种方式生产环境建议直接用 JWT可观测性内建Control API9997和 Prometheus 指标9998都是编译进二进制的能力不需要 sidecar。单二进制、无运行时依赖意味着镜像可以小到极致——官方 Docker 构建文件 的终点是FROM scratch里面只有/mediamtx可执行文件本身多架构AMD64/ARMv6/ARMv7/ARM64由TARGETPLATFORM自动适配。最小可行部署5 分钟跑通先跑通再调优。官方镜像是 multi-arch 的一条docker run就能起docker run --rm -it --networkhost \ -e MTX_APIyes \ bluenviron/mediamtx:1--networkhost是因为 RTSP 的 UDP RTP/RTCP8000/8001、WebRTC 的 UDP8189都需要直通宿主机网络端口映射在这里反而添乱。MTX_APIyes开启 Control API方便我们验证。起流验证终端里推一路测试流ffmpeg -re -i test.mp4 -c copy -f rtsp rtsp://localhost:8554/test另开终端拉 HLS 播放列表curl -s http://localhost:8888/test/index.m3u8能看到.m3u8内容说明 RTSP 进、HLS 出的转码链路通了。再看一眼 APIcurl -s http://localhost:9997/v3/paths返回的 JSON 里会出现test这个 path 和它的读者数。三条命令走完你对它活着、在干活就有直接感知了。生产级配置按维度展开配置有三种改法改配置文件镜像内路径/mediamtx.yml支持热重载、环境变量MTX_参数名如MTX_RTSPADDRESS数组用逗号分隔、以及 Control API。容器场景下静态配置走挂载的 配置文件动态值走环境变量这是最常用的组合。网络与端口让外部客户端找得到你核心目标是让 NAT 后面的客户端尤其 WebRTC能建连。关键项# ... webrtcAdditionalHosts: [203.0.113.10] # 你的公网 IP udpReadBufferSize: 2097152 # UDP 读缓冲区 2MB rtspTransports: [udp, tcp] # 按客户端情况裁剪参数作用推荐值webrtcAdditionalHosts告诉 ICE 服务器对外暴露的地址局域网主机名不够用时必填公网 IP 列表udpReadBufferSize内核之上的 UDP 读缓冲默认0表示用系统默认值20971522MBrtspTransports开启的传输方式默认含 multicast公网用不上按需保留 tcp/udp资源与性能把带宽花在有人看的流上如果每路流都是拉上游源的代理没人看时白白占着上行带宽。核心目标是按需拉源pathDefaults: # ... sourceOnDemand: true # 有第一个读者才拉源 sourceOnDemandCloseAfter: 30s # 无读者 30s 后关源 sourceOnDemandStartTimeout: 10s # 等源的读者最多挂起 10s maxReaders: 100 # 单 path 并发上限0 为不限sourceOnDemand适合源在远端、观众稀疏的场景如果推流端是本地摄像头保持默认false即可避免观众进出导致源反复重连。maxReaders建议按业务容量设一个硬顶防止单路异常流吃满出口。认证与安全默认配置是裸奔的MediaMTX 默认不认证、不加密公网部署前必须收口rtspEncryption: optional # 同时监听 8554(明文) 与 8322(RTSPS) webrtcEncryption: true # WebRTC 强制 TLS authJWTJWKS: https://your-idp/.well-known/jwks.json authJWTClaimKey: mediamtx_permissions参数作用推荐值rtspEncryptionRTSPS 加密开关可选no/optional/strict过渡期optional稳定后strictauthJWTJWKS用 JWKS 端点校验 JWT权限声明放在指定 claim 里指向 IdP 的 JWKS URLwebrtcEncryption强制 WebRTC 走安全传输trueoptional的意义是让存量明文客户端平滑迁移而不是第一天就strict把老设备全打挂。可靠性与可观测性健康检查与自愈注意官方镜像是scratch底座容器里没有 shell 和 curlDocker 的test: [CMD, ...]健康检查在这张镜像上跑不了。正确做法是把探测放到容器外K8s 的httpGet探针正合适livenessProbe: httpGet: path: /v3/paths port: 9997 initialDelaySeconds: 5 periodSeconds: 10前提是配置里api: true或MTX_APIyes。API 进程和媒体服务同生共死API 不响应基本可以断定进程卡死探针杀掉重建即可。多副本加一条topologySpreadConstraintstopologyKey: topology.kubernetes.io/zone就能摊到多可用区。指标暴露与告警开启 metrics 后直接curl http://localhost:9998/metricsmetrics: true metricsAddress: :9998指标按协议和 path 带标签最有用的几个paths_readers{name, state, readerType}每条路径的读者数按协议区分扩容决策直接看它paths_inbound_bytes/paths_outbound_bytes单路出入流量定位带宽大户rtsp_sessions_inbound_rtp_packets_lost入向 RTP 丢包数网络质量告警的依据。HPA 按 CPU 扩是兜底paths_readers总和这类自定义指标更接近业务语义有 Prometheus Adapter 之后可以挂上去。日志策略容器场景下日志走 stdout 交给平台收集本地文件只是排障备份logLevel: info logDestinations: [stdout, file] logFile: /mediamtx.log logStructured: true # JSONL 格式Loki/CloudWatch 解析更稳logStructured: true值得在 K8s 里直接开JSONL 日志进 Loki 或 CloudWatch 时按字段索引比正则抠文本可靠得多。注意 scratch 镜像下日志文件落在容器内容器重建即消失所以文件只是临时证据长期检索依赖 stdout 链路。这三件事做完线上出问题时你能在 1 分钟内定位探针日志告诉你 Pod 死了没有/metrics告诉你哪条路径异常结构化日志告诉你断连的确切原因和时间点。常见踩坑与调优WebRTC 浏览器端连不上RTSP 却正常→ ICE 协商不到公网候选。原因几乎总是容器内只能看到内网 IP。解法把公网 IP 写进webrtcAdditionalHosts或让 STUN 可达改完用v3/paths确认会话建立。UDP 拉流偶发卡顿、丢包→ 很多人第一次部署会踩这个坑udpReadBufferSize默认是0系统默认值大流量下内核缓冲不够。解法显式设 2MB 起同时查一下节点net.core.rmem_default。改配置后服务没反应→ 配置文件热重载的前提是你改的是监听中的那份文件环境变量覆盖优先级高于文件。排查curl localhost:9997/v3/config/global直接看运行时生效值。sourceOnDemand开了观众首帧变慢→ 正常现象读者要等源就绪sourceOnDemandStartTimeout内挂起。源本身响应慢的话把超时调大或对该 path 单独关闭 onDemand。9997 端口不响应→api默认是false不是挂了。部署时记得通过MTX_APIyes或配置开启健康检查也依赖它。落地路径建议验证期单节点docker run起服务推一路测试流跑通RTSP 进 → HLS 出把端口清单和网络策略先和基础设施团队对齐稳定期迁移到 K8s Deployment开启api liveness 探针 JWT 认证日志切 JSONL 接入现有采集链路跑一两周观察资源基线优化期按paths_readers自定义指标上 HPA多可用区铺开把rtspEncryption从optional收紧到strict。配置都是热重载的改一个参数就能看效果——现在就可以拉一份 mediamtx.yml 到自己环境里试跑。【免费下载链接】mediamtxReady-to-use Media-over-QUIC / SRT / WebRTC / RTSP / RTMP / LL-HLS / MPEG-TS / RTP live media server and media proxy that allows to read, publish, proxy, record and playback real-time video and audio streams.项目地址: https://gitcode.com/GitHub_Trending/me/mediamtx创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
MediaMTX 上 K8s：零停机部署到生产集群的完整路径
MediaMTX 上 K8s零停机部署到生产集群的完整路径【免费下载链接】mediamtxReady-to-use Media-over-QUIC / SRT / WebRTC / RTSP / RTMP / LL-HLS / MPEG-TS / RTP live media server and media proxy that allows to read, publish, proxy, record and playback real-time video and audio streams.项目地址: https://gitcode.com/GitHub_Trending/me/mediamtx凌晨两点直播推流中断值班人员只能重启一整台虚机。如果流媒体服务本身就是一个无状态容器重启只需要几秒。MediaMTX 是一个零依赖的实时媒体服务器能把 RTSP/RTMP/HLS/WebRTC/SRT 等协议互相转换并转发我们部署它就是为了把重启一台机器变成替换一个 Pod。本文覆盖最小部署、生产配置和可观测性三块。项目能做什么 / 核心能力速览MediaMTX 把自己定位成media router流从一端进来按需转换协议后从另一端出去全程不落地转码所以延迟和 CPU 消耗都很低。几个关键能力全协议接入与互转推流支持 Media-over-QUIC、SRT、WebRTC、RTSP、RTMP、HLS、MPEG-TS、RTP拉流支持前六类同一路流可以同时被多种协议消费热重载配置修改配置文件后不踢掉已有客户端这是它能做零停机部署的前提录像与回放以 fMP4 或 MPEG-TS 分段落盘回放走独立的 playback 服务默认端口 9996认证体系内置用户、HTTP 回调、JWT 三种方式生产环境建议直接用 JWT可观测性内建Control API9997和 Prometheus 指标9998都是编译进二进制的能力不需要 sidecar。单二进制、无运行时依赖意味着镜像可以小到极致——官方 Docker 构建文件 的终点是FROM scratch里面只有/mediamtx可执行文件本身多架构AMD64/ARMv6/ARMv7/ARM64由TARGETPLATFORM自动适配。最小可行部署5 分钟跑通先跑通再调优。官方镜像是 multi-arch 的一条docker run就能起docker run --rm -it --networkhost \ -e MTX_APIyes \ bluenviron/mediamtx:1--networkhost是因为 RTSP 的 UDP RTP/RTCP8000/8001、WebRTC 的 UDP8189都需要直通宿主机网络端口映射在这里反而添乱。MTX_APIyes开启 Control API方便我们验证。起流验证终端里推一路测试流ffmpeg -re -i test.mp4 -c copy -f rtsp rtsp://localhost:8554/test另开终端拉 HLS 播放列表curl -s http://localhost:8888/test/index.m3u8能看到.m3u8内容说明 RTSP 进、HLS 出的转码链路通了。再看一眼 APIcurl -s http://localhost:9997/v3/paths返回的 JSON 里会出现test这个 path 和它的读者数。三条命令走完你对它活着、在干活就有直接感知了。生产级配置按维度展开配置有三种改法改配置文件镜像内路径/mediamtx.yml支持热重载、环境变量MTX_参数名如MTX_RTSPADDRESS数组用逗号分隔、以及 Control API。容器场景下静态配置走挂载的 配置文件动态值走环境变量这是最常用的组合。网络与端口让外部客户端找得到你核心目标是让 NAT 后面的客户端尤其 WebRTC能建连。关键项# ... webrtcAdditionalHosts: [203.0.113.10] # 你的公网 IP udpReadBufferSize: 2097152 # UDP 读缓冲区 2MB rtspTransports: [udp, tcp] # 按客户端情况裁剪参数作用推荐值webrtcAdditionalHosts告诉 ICE 服务器对外暴露的地址局域网主机名不够用时必填公网 IP 列表udpReadBufferSize内核之上的 UDP 读缓冲默认0表示用系统默认值20971522MBrtspTransports开启的传输方式默认含 multicast公网用不上按需保留 tcp/udp资源与性能把带宽花在有人看的流上如果每路流都是拉上游源的代理没人看时白白占着上行带宽。核心目标是按需拉源pathDefaults: # ... sourceOnDemand: true # 有第一个读者才拉源 sourceOnDemandCloseAfter: 30s # 无读者 30s 后关源 sourceOnDemandStartTimeout: 10s # 等源的读者最多挂起 10s maxReaders: 100 # 单 path 并发上限0 为不限sourceOnDemand适合源在远端、观众稀疏的场景如果推流端是本地摄像头保持默认false即可避免观众进出导致源反复重连。maxReaders建议按业务容量设一个硬顶防止单路异常流吃满出口。认证与安全默认配置是裸奔的MediaMTX 默认不认证、不加密公网部署前必须收口rtspEncryption: optional # 同时监听 8554(明文) 与 8322(RTSPS) webrtcEncryption: true # WebRTC 强制 TLS authJWTJWKS: https://your-idp/.well-known/jwks.json authJWTClaimKey: mediamtx_permissions参数作用推荐值rtspEncryptionRTSPS 加密开关可选no/optional/strict过渡期optional稳定后strictauthJWTJWKS用 JWKS 端点校验 JWT权限声明放在指定 claim 里指向 IdP 的 JWKS URLwebrtcEncryption强制 WebRTC 走安全传输trueoptional的意义是让存量明文客户端平滑迁移而不是第一天就strict把老设备全打挂。可靠性与可观测性健康检查与自愈注意官方镜像是scratch底座容器里没有 shell 和 curlDocker 的test: [CMD, ...]健康检查在这张镜像上跑不了。正确做法是把探测放到容器外K8s 的httpGet探针正合适livenessProbe: httpGet: path: /v3/paths port: 9997 initialDelaySeconds: 5 periodSeconds: 10前提是配置里api: true或MTX_APIyes。API 进程和媒体服务同生共死API 不响应基本可以断定进程卡死探针杀掉重建即可。多副本加一条topologySpreadConstraintstopologyKey: topology.kubernetes.io/zone就能摊到多可用区。指标暴露与告警开启 metrics 后直接curl http://localhost:9998/metricsmetrics: true metricsAddress: :9998指标按协议和 path 带标签最有用的几个paths_readers{name, state, readerType}每条路径的读者数按协议区分扩容决策直接看它paths_inbound_bytes/paths_outbound_bytes单路出入流量定位带宽大户rtsp_sessions_inbound_rtp_packets_lost入向 RTP 丢包数网络质量告警的依据。HPA 按 CPU 扩是兜底paths_readers总和这类自定义指标更接近业务语义有 Prometheus Adapter 之后可以挂上去。日志策略容器场景下日志走 stdout 交给平台收集本地文件只是排障备份logLevel: info logDestinations: [stdout, file] logFile: /mediamtx.log logStructured: true # JSONL 格式Loki/CloudWatch 解析更稳logStructured: true值得在 K8s 里直接开JSONL 日志进 Loki 或 CloudWatch 时按字段索引比正则抠文本可靠得多。注意 scratch 镜像下日志文件落在容器内容器重建即消失所以文件只是临时证据长期检索依赖 stdout 链路。这三件事做完线上出问题时你能在 1 分钟内定位探针日志告诉你 Pod 死了没有/metrics告诉你哪条路径异常结构化日志告诉你断连的确切原因和时间点。常见踩坑与调优WebRTC 浏览器端连不上RTSP 却正常→ ICE 协商不到公网候选。原因几乎总是容器内只能看到内网 IP。解法把公网 IP 写进webrtcAdditionalHosts或让 STUN 可达改完用v3/paths确认会话建立。UDP 拉流偶发卡顿、丢包→ 很多人第一次部署会踩这个坑udpReadBufferSize默认是0系统默认值大流量下内核缓冲不够。解法显式设 2MB 起同时查一下节点net.core.rmem_default。改配置后服务没反应→ 配置文件热重载的前提是你改的是监听中的那份文件环境变量覆盖优先级高于文件。排查curl localhost:9997/v3/config/global直接看运行时生效值。sourceOnDemand开了观众首帧变慢→ 正常现象读者要等源就绪sourceOnDemandStartTimeout内挂起。源本身响应慢的话把超时调大或对该 path 单独关闭 onDemand。9997 端口不响应→api默认是false不是挂了。部署时记得通过MTX_APIyes或配置开启健康检查也依赖它。落地路径建议验证期单节点docker run起服务推一路测试流跑通RTSP 进 → HLS 出把端口清单和网络策略先和基础设施团队对齐稳定期迁移到 K8s Deployment开启api liveness 探针 JWT 认证日志切 JSONL 接入现有采集链路跑一两周观察资源基线优化期按paths_readers自定义指标上 HPA多可用区铺开把rtspEncryption从optional收紧到strict。配置都是热重载的改一个参数就能看效果——现在就可以拉一份 mediamtx.yml 到自己环境里试跑。【免费下载链接】mediamtxReady-to-use Media-over-QUIC / SRT / WebRTC / RTSP / RTMP / LL-HLS / MPEG-TS / RTP live media server and media proxy that allows to read, publish, proxy, record and playback real-time video and audio streams.项目地址: https://gitcode.com/GitHub_Trending/me/mediamtx创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
