企业官网建设流程全解析

MediaMTX 部署完整指南：从单机 Docker 到 Kubernetes 高可用的 3 条路

【免费下载链接】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 是一款支持 SRT、WebRTC、RTSP、RTMP、HLS 等多协议的实时媒体服务器，既能转推直播流，也能录制和回放。按本指南的 MediaMTX Docker 部署路线走一遍：先用一条命令在单机上跑起来，再改掉 mediamtx.yml 里最关键的几个开关，最后把服务升级到 Kubernetes 集群。零基础也能走完全程。

一、先选路线：单机还是集群

这一步做完，你会知道自己该用哪种方式部署，避免一上来就堆复杂度。

推荐路径：先用 Docker 单机验证，业务跑顺了再迁到 K8s。两阶段的配置基本通用，迁移成本低。

二、最快上手：一条命令部署 MediaMTX

这一步做完，你会得到一个正在监听全部常用端口的 mediamtx 容器，并且能用浏览器或播放器确认它在服务。

docker pull bluenviron/mediamtx docker run -d --name mediamtx --restart unless-stopped \ -p 1935:1935 \ -p 8554:8554 \ -p 8888:8888 \ -p 8889:8889 \ -p 8890:8890 \ -p 9997:9997 \ -p 9998:9998 \ -v $(pwd)/mediamtx.yml:/mediamtx.yml:ro \ -v $(pwd)/recordings:/recordings \ bluenviron/mediamtx

各端口对应关系记一下：

• 1935：RTMP
• 8554：RTSP
• 8888：HLS
• 8889：WebRTC
• 8890：SRT
• 9997：控制 API
• 9998：Metrics 指标

配置文件可以不用改，仓库里自带的 mediamtx.yml 就是完整默认配置，拷出来直接挂载即可。跑完执行下面这步验证：

• 访问http://localhost:9997/v3/info，能返回 JSON 说明控制 API 活着
• 用 VLC 打开rtsp://localhost:8554/<你的流名>，或推一路流到rtmp://localhost:1935/<你的流名>试读

如果单机还要带周边服务，把上面的docker run换成 Compose 更省事，服务、端口、卷都写在一个文件里，docker compose up -d即可。

三、mediamtx.yml 必动的 6 个配置项

这一步做完，你会清楚哪些开关真正影响行为，改配置不再靠猜。完整配置不用看，新手容易改错的就这 6 处：

录制相关配置放在pathDefaults下，对所有路径生效。只给个别流单独设置时，才需要在paths里建同名段落覆盖。

四、集群升级：MediaMTX 上 Kubernetes

这一步做完，你会拿到一套多副本的部署：请求先进 Service，再被分发到后端任意一个 mediamtx Pod，录像落到共享存储上。

资源按这个顺序kubectl apply，依赖才不会断：

kubectl apply -f namespace.yaml kubectl apply -f pvc.yaml kubectl apply -f configmap.yaml kubectl apply -f deployment.yaml kubectl apply -f service.yaml

清单本身不复杂，真正要盯住的是这 3 个点：

1. 探活：liveness 和 readiness 都打控制 API 的/v3/info（9997 端口），比打媒体端口可靠。示例：

livenessProbe: httpGet: path: /v3/info port: api initialDelaySeconds: 30 periodSeconds: 10

2. 副本数：replicas从 2 起步，配RollingUpdate策略保证升级不中断。注意 mediamtx 是多播式服务，同一路流的推流端和拉流端可能落在不同 Pod 上，客户端要支持按流名重新路由或改用单推流入口。
3. 存储：录像目录挂 ReadWriteMany 的 PVC（如 nfs 类 storageClass），多 Pod 共享写入；recordDeleteAfter负责自动清理，别忘了配。

Service 把 1935 / 8554 / 8888 / 8889 / 8890 / 9997 / 9998 逐个声明为端口条目即可，协议默认 TCP；WebRTC 还要放通 UDP 范围，SRT 走 8890。

五、生产环境清单

集群跑起来之后，把下面 4 项逐项过一遍，每项一两句话就能落地：

• 监控：Prometheus 直接抓 9998 端口的/metrics，Pod 上打prometheus.io/scrape注解或建 ServiceMonitor，告警盯连接数与进程存活。
• 自动扩缩容：HPA 指向 deployment，CPU 利用率 70% 左右触发扩容，minReplicas2、maxReplicas按预算设。
• 网络策略：NetworkPolicy 只放行媒体端口的入向流量和 DNS 出向，其余全拒，缩小暴露面。
• TLS：对外暴露的 RTSP / SRT / WebRTC 配置各自的 TLS 证书项，证书可用 cert-manager 签发并自动续期，避免手写证书过期翻车。

更多协议细节（SRT 参数、WebRTC 打洞等）建议直接翻仓库里的 docs/ 目录，按协议查对应章节。

六、出问题先查这里

到这里，单机到集群的完整链路就走完了。下一步可以按这个顺序推进：

• 给自己的一路真实业务流做 24 小时录制压测
• 给/metrics配上至少两条告警（进程存活、连接数突增）
• 演练一次 PVC 备份与恢复，确认真出事时拿得回录像

【免费下载链接】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