MediaMTX 容器化部署实战Docker 到 K8s 集群的 7 步落地【免费下载链接】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凌晨三点手机被监控告警震醒流媒体节点 RTSP 连接数归零早高峰的直播流全断了。排查半天发现是老问题——服务器重启后进程没拉起来手写的启动脚本连个重启策略都没有。这类节点一挂、流全断的麻烦根子在于部署方式太裸二进制往机器上一扔就完事。MediaMTX 是一个开箱即用的实时媒体服务器支持 SRT、WebRTC、RTSP、RTMP、HLS 等主流协议既能读流、推流、代理也能录制和回放。它本身是单二进制 一份mediamtx.yml的配置形态天生适合容器化。这篇文章按真实任务流走一遍先用一条命令跑起来再交给 Docker Compose 管住最后落到 K8s 集群上把配置、流量、高可用三件事一次性解决。一条命令拉起 MediaMTX 官方镜像是bluenviron/mediamtx基于 scratch 构建只装了对应架构的二进制镜像极小且没有 shell——别指望docker exec -it ... sh进去看东西排障要靠日志和 API。镜像里约定配置文件放在/mediamtx.yml所以挂载时直接覆盖这个路径即可。下面这条docker run把 7 个协议/管理端口全部映射出来注释只写协议名具体干什么你扫一眼 mediamtx.yml 官方配置 就能对上docker run -d \ --name mediamtx \ --restart unless-stopped \ -p 1935:1935 \ # RTMP -p 8554:8554 \ # RTSP -p 8888:8888 \ # HLS -p 8889:8889 \ # WebRTC -p 8890:8890 \ # SRT -p 9997:9997 \ # Control API -p 9998:9998 \ # Metrics -v $(pwd)/mediamtx.yml:/mediamtx.yml:ro \ -v $(pwd)/recordings:/recordings \ bluenviron/mediamtx两个细节值得注意配置文件加:ro只读挂载容器不需要写它省得被误改recordings目录单独挂出来录制片段才有地方落盘。跑起来之后curl http://localhost:9997/v3/info能返回服务信息说明节点活着。把配置搬进 Docker Compose 编排单机docker run只是热身端口清单、挂载、重启策略散在命令行里换台机器就要重抄一遍。Compose 的价值不在端口而在于配置文件怎么组织。推荐的目录结构是把配置和录像数据分开两个目录配置文件进版本控制deploy/ ├── docker-compose.yml ├── config/mediamtx.yml # 进 git改动走 review └── recordings/ # 数据目录挂数据盘编排文件只关心 services 的核心字段端口清单和上面一致这里不再重复罗列services: mediamtx: image: bluenviron/mediamtx:latest container_name: mediamtx restart: unless-stopped # 宿主机重启后自动拉起 ports: - 1935:1935 # RTMP - 8554:8554 # RTSP - 8888:8888 # HLS - 8889:8889 # WebRTC - 8890:8890 # SRT - 9997:9997 # Control API - 9998:9998 # Metrics volumes: - ./config/mediamtx.yml:/mediamtx.yml:ro - ./recordings:/recordings environment: - TZAsia/Shanghai # 录制文件名按本地时区生成 networks: - mediamtx-net networks: mediamtx-net: driver: bridgeTZ这个环境变量容易被忽略但它决定录制文件名的时区跨时区运维时排查问题会用到。启动和日常操作就是这几条docker compose up -d # 启动 docker compose logs -f # 跟踪日志 docker compose pull docker compose up -d # 升级镜像上生产K8s 方案 真正上生产你得盯住三件事配置怎么管、流量怎么进、挂了谁来接。K8s 方案按 Namespace → ConfigMap → Deployment → Service → PVC → ServiceMonitor 的顺序铺资源整体架构如下下面逐个说资源对象每段只保留为什么这么写的关键字段。Namespace 隔离环境两行带标签方便后续按命名空间做资源配额和网络策略apiVersion: v1 kind: Namespace metadata: name: mediamtx labels: app.kubernetes.io/name: mediamtx配置进 ConfigMap。这里不贴完整mediamtx.yml只写影响生产的几项其余协议开关照抄默认配置即可apiVersion: v1 kind: ConfigMap metadata: name: mediamtx-config namespace: mediamtx data: mediamtx.yml: | logLevel: info api: yes metrics: yes pathDefaults: record: yes # ... 其余协议开关同上MediaMTX 支持热加载配置文件但走 ConfigMap 改动后需要重建 Pod 才生效所以生产上把配置视为发布物改动走 Git。Deployment 里最关键的是探针和资源限制它决定 Pod 什么时候被判死、什么时候被调度器踢走spec: replicas: 3 template: spec: containers: - name: mediamtx image: bluenviron/mediamtx:latest # 探针打 Control API 的 /v3/info能返回 200 即视为存活 livenessProbe: httpGet: { path: /v3/info, port: 9997 } initialDelaySeconds: 30 periodSeconds: 10 readinessProbe: httpGet: { path: /v3/info, port: 9997 } initialDelaySeconds: 5 periodSeconds: 5 resources: requests: { memory: 256Mi, cpu: 250m } limits: { memory: 1Gi, cpu: 1 }注意 liveness 的initialDelaySeconds别设太短MediaMTX 启动时要初始化所有协议监听器给 30 秒缓冲能避免启动期的误杀。Service 负责流量怎么进。选 LoadBalancer 类型让云厂商直接挂外部 IP注意 RTSP/SRT 这类长连接协议对四层负载更友好HLS/WebRTC 走七层也行apiVersion: v1 kind: Service metadata: name: mediamtx namespace: mediamtx spec: type: LoadBalancer # 云上直接分配外部 IP省一层 Ingress selector: app: mediamtx ports: - { name: rtsp, port: 8554, targetPort: 8554 } - { name: hls, port: 8888, targetPort: 8888 } # ... 其余端口按 RTMP/SRT/API/Metrics 同理PVC 承载录制数据。3 个 Pod 同时写必须选ReadWriteMany所以底层存储要走 NFS 或云上支持多挂载的卷apiVersion: v1 kind: PersistentVolumeClaim metadata: name: mediamtx-recordings namespace: mediamtx spec: accessModes: [ReadWriteMany] # 多副本共享写入的关键 resources: requests: storage: 100Gi如果暂时不需要多副本共享录制退一步用每副本一个ReadWriteOnce的 PVC 更省心——录制的多副本一致性问题本就不该硬扛。最后 ServiceMonitor 让 Prometheus 按 30 秒周期抓每个 Pod 的:9998/metrics这里只列核心选择器release: prometheus标签对齐你集群里 Prometheus Operator 的 labelapiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: mediamtx-monitor namespace: mediamtx spec: selector: matchLabels: app: mediamtx endpoints: - port: metrics path: /metrics interval: 30s全部丢给 kubectl 按依赖顺序应用然后确认 Pod 就绪kubectl apply -f namespace.yaml kubectl apply -f configmap.yaml kubectl apply -f pvc.yaml kubectl apply -f deployment.yaml kubectl apply -f service.yaml kubectl apply -f servicemonitor.yaml kubectl get pods,svc -n mediamtx运维三板斧监控、安全、排障监控ServiceMonitor 配好后Prometheus 里直接就能查mediamtx_path_readers、mediamtx_path_publishers这类按 path 维度的指标。不接 Prometheus 也能临时肉眼看一遍curl -s http://node-ip:9998/metrics | grep mediamtx_path安全NetworkPolicy 的核心思路是默认全拒、按端口放行——只放行 1935/8554/8888/8889/8890 和出方向的 DNS管理端口 9997/9998 只允许内网网段访问别让 Control API 裸露公网。TLS 则交给 cert-manager 签发配置里对应协议的tls: yes加证书路径即可证书轮转不用人盯。排障日常 90% 的问题落在这三种现象里现象常见原因解法客户端连接超时NetworkPolicy 或云安全组没放行对应端口对照 Service 端口清单逐项核对放行规则推流成功但拉流 404客户端用的 path 与推流 path 不一致curl :9997/v3/paths/list确认 path 是否存在录制目录为空PVC 未就绪或record: yes未生效kubectl describe pod看挂载状态查 ConfigMap 里的 pathDefaults调优与弹性HPA 别照搬模板关键是两个参数要匹配业务minReplicas: 2保底高可用maxReplicas按你能承受的节点成本给CPU 目标averageUtilization建议 70因为 MediaMTX 的开销主要在转发和封装CPU 打满前内存往往先紧。资源请求/限制给一组起步值requests250m / 256Milimits1 / 1Gi跑一周看 P95 再回调。另一个容易踩的坑HPA 只能横向扩无状态部分。MediaMTX 同一 path 的推流只会落在某一个 Pod 上副本之间不共享流会话所以扩副本解决的是总连接数问题不是单流卡顿问题。单流质量靠的是每副本的网络水位writeQueueSize、udpReadBufferSize这些参数别指望堆 Pod 数。行动清单在一台干净的测试机上用docker run跑通 MediaMTX/v3/info返回正常把mediamtx.yml收进 Git用 Compose 管理配置和录制目录验证升级流程pull up -dK8s 环境按 Namespace → ConfigMap → PVC → Deployment → Service 顺序应用资源确认 3 副本全部 Ready接上 ServiceMonitor在 Grafana 里加mediamtx_path_readers和mediamtx_path_publishers两块面板配好 NetworkPolicy 后做一次回归RTSP 拉流、HLS 拉流、API 查询三件事都能走通压测一轮后再定 HPA 的maxReplicas和资源 limits别用拍脑袋的数字上生产【免费下载链接】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 容器化部署实战：Docker 到 K8s 集群的 7 步落地
MediaMTX 容器化部署实战Docker 到 K8s 集群的 7 步落地【免费下载链接】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凌晨三点手机被监控告警震醒流媒体节点 RTSP 连接数归零早高峰的直播流全断了。排查半天发现是老问题——服务器重启后进程没拉起来手写的启动脚本连个重启策略都没有。这类节点一挂、流全断的麻烦根子在于部署方式太裸二进制往机器上一扔就完事。MediaMTX 是一个开箱即用的实时媒体服务器支持 SRT、WebRTC、RTSP、RTMP、HLS 等主流协议既能读流、推流、代理也能录制和回放。它本身是单二进制 一份mediamtx.yml的配置形态天生适合容器化。这篇文章按真实任务流走一遍先用一条命令跑起来再交给 Docker Compose 管住最后落到 K8s 集群上把配置、流量、高可用三件事一次性解决。一条命令拉起 MediaMTX 官方镜像是bluenviron/mediamtx基于 scratch 构建只装了对应架构的二进制镜像极小且没有 shell——别指望docker exec -it ... sh进去看东西排障要靠日志和 API。镜像里约定配置文件放在/mediamtx.yml所以挂载时直接覆盖这个路径即可。下面这条docker run把 7 个协议/管理端口全部映射出来注释只写协议名具体干什么你扫一眼 mediamtx.yml 官方配置 就能对上docker run -d \ --name mediamtx \ --restart unless-stopped \ -p 1935:1935 \ # RTMP -p 8554:8554 \ # RTSP -p 8888:8888 \ # HLS -p 8889:8889 \ # WebRTC -p 8890:8890 \ # SRT -p 9997:9997 \ # Control API -p 9998:9998 \ # Metrics -v $(pwd)/mediamtx.yml:/mediamtx.yml:ro \ -v $(pwd)/recordings:/recordings \ bluenviron/mediamtx两个细节值得注意配置文件加:ro只读挂载容器不需要写它省得被误改recordings目录单独挂出来录制片段才有地方落盘。跑起来之后curl http://localhost:9997/v3/info能返回服务信息说明节点活着。把配置搬进 Docker Compose 编排单机docker run只是热身端口清单、挂载、重启策略散在命令行里换台机器就要重抄一遍。Compose 的价值不在端口而在于配置文件怎么组织。推荐的目录结构是把配置和录像数据分开两个目录配置文件进版本控制deploy/ ├── docker-compose.yml ├── config/mediamtx.yml # 进 git改动走 review └── recordings/ # 数据目录挂数据盘编排文件只关心 services 的核心字段端口清单和上面一致这里不再重复罗列services: mediamtx: image: bluenviron/mediamtx:latest container_name: mediamtx restart: unless-stopped # 宿主机重启后自动拉起 ports: - 1935:1935 # RTMP - 8554:8554 # RTSP - 8888:8888 # HLS - 8889:8889 # WebRTC - 8890:8890 # SRT - 9997:9997 # Control API - 9998:9998 # Metrics volumes: - ./config/mediamtx.yml:/mediamtx.yml:ro - ./recordings:/recordings environment: - TZAsia/Shanghai # 录制文件名按本地时区生成 networks: - mediamtx-net networks: mediamtx-net: driver: bridgeTZ这个环境变量容易被忽略但它决定录制文件名的时区跨时区运维时排查问题会用到。启动和日常操作就是这几条docker compose up -d # 启动 docker compose logs -f # 跟踪日志 docker compose pull docker compose up -d # 升级镜像上生产K8s 方案 真正上生产你得盯住三件事配置怎么管、流量怎么进、挂了谁来接。K8s 方案按 Namespace → ConfigMap → Deployment → Service → PVC → ServiceMonitor 的顺序铺资源整体架构如下下面逐个说资源对象每段只保留为什么这么写的关键字段。Namespace 隔离环境两行带标签方便后续按命名空间做资源配额和网络策略apiVersion: v1 kind: Namespace metadata: name: mediamtx labels: app.kubernetes.io/name: mediamtx配置进 ConfigMap。这里不贴完整mediamtx.yml只写影响生产的几项其余协议开关照抄默认配置即可apiVersion: v1 kind: ConfigMap metadata: name: mediamtx-config namespace: mediamtx data: mediamtx.yml: | logLevel: info api: yes metrics: yes pathDefaults: record: yes # ... 其余协议开关同上MediaMTX 支持热加载配置文件但走 ConfigMap 改动后需要重建 Pod 才生效所以生产上把配置视为发布物改动走 Git。Deployment 里最关键的是探针和资源限制它决定 Pod 什么时候被判死、什么时候被调度器踢走spec: replicas: 3 template: spec: containers: - name: mediamtx image: bluenviron/mediamtx:latest # 探针打 Control API 的 /v3/info能返回 200 即视为存活 livenessProbe: httpGet: { path: /v3/info, port: 9997 } initialDelaySeconds: 30 periodSeconds: 10 readinessProbe: httpGet: { path: /v3/info, port: 9997 } initialDelaySeconds: 5 periodSeconds: 5 resources: requests: { memory: 256Mi, cpu: 250m } limits: { memory: 1Gi, cpu: 1 }注意 liveness 的initialDelaySeconds别设太短MediaMTX 启动时要初始化所有协议监听器给 30 秒缓冲能避免启动期的误杀。Service 负责流量怎么进。选 LoadBalancer 类型让云厂商直接挂外部 IP注意 RTSP/SRT 这类长连接协议对四层负载更友好HLS/WebRTC 走七层也行apiVersion: v1 kind: Service metadata: name: mediamtx namespace: mediamtx spec: type: LoadBalancer # 云上直接分配外部 IP省一层 Ingress selector: app: mediamtx ports: - { name: rtsp, port: 8554, targetPort: 8554 } - { name: hls, port: 8888, targetPort: 8888 } # ... 其余端口按 RTMP/SRT/API/Metrics 同理PVC 承载录制数据。3 个 Pod 同时写必须选ReadWriteMany所以底层存储要走 NFS 或云上支持多挂载的卷apiVersion: v1 kind: PersistentVolumeClaim metadata: name: mediamtx-recordings namespace: mediamtx spec: accessModes: [ReadWriteMany] # 多副本共享写入的关键 resources: requests: storage: 100Gi如果暂时不需要多副本共享录制退一步用每副本一个ReadWriteOnce的 PVC 更省心——录制的多副本一致性问题本就不该硬扛。最后 ServiceMonitor 让 Prometheus 按 30 秒周期抓每个 Pod 的:9998/metrics这里只列核心选择器release: prometheus标签对齐你集群里 Prometheus Operator 的 labelapiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: mediamtx-monitor namespace: mediamtx spec: selector: matchLabels: app: mediamtx endpoints: - port: metrics path: /metrics interval: 30s全部丢给 kubectl 按依赖顺序应用然后确认 Pod 就绪kubectl apply -f namespace.yaml kubectl apply -f configmap.yaml kubectl apply -f pvc.yaml kubectl apply -f deployment.yaml kubectl apply -f service.yaml kubectl apply -f servicemonitor.yaml kubectl get pods,svc -n mediamtx运维三板斧监控、安全、排障监控ServiceMonitor 配好后Prometheus 里直接就能查mediamtx_path_readers、mediamtx_path_publishers这类按 path 维度的指标。不接 Prometheus 也能临时肉眼看一遍curl -s http://node-ip:9998/metrics | grep mediamtx_path安全NetworkPolicy 的核心思路是默认全拒、按端口放行——只放行 1935/8554/8888/8889/8890 和出方向的 DNS管理端口 9997/9998 只允许内网网段访问别让 Control API 裸露公网。TLS 则交给 cert-manager 签发配置里对应协议的tls: yes加证书路径即可证书轮转不用人盯。排障日常 90% 的问题落在这三种现象里现象常见原因解法客户端连接超时NetworkPolicy 或云安全组没放行对应端口对照 Service 端口清单逐项核对放行规则推流成功但拉流 404客户端用的 path 与推流 path 不一致curl :9997/v3/paths/list确认 path 是否存在录制目录为空PVC 未就绪或record: yes未生效kubectl describe pod看挂载状态查 ConfigMap 里的 pathDefaults调优与弹性HPA 别照搬模板关键是两个参数要匹配业务minReplicas: 2保底高可用maxReplicas按你能承受的节点成本给CPU 目标averageUtilization建议 70因为 MediaMTX 的开销主要在转发和封装CPU 打满前内存往往先紧。资源请求/限制给一组起步值requests250m / 256Milimits1 / 1Gi跑一周看 P95 再回调。另一个容易踩的坑HPA 只能横向扩无状态部分。MediaMTX 同一 path 的推流只会落在某一个 Pod 上副本之间不共享流会话所以扩副本解决的是总连接数问题不是单流卡顿问题。单流质量靠的是每副本的网络水位writeQueueSize、udpReadBufferSize这些参数别指望堆 Pod 数。行动清单在一台干净的测试机上用docker run跑通 MediaMTX/v3/info返回正常把mediamtx.yml收进 Git用 Compose 管理配置和录制目录验证升级流程pull up -dK8s 环境按 Namespace → ConfigMap → PVC → Deployment → Service 顺序应用资源确认 3 副本全部 Ready接上 ServiceMonitor在 Grafana 里加mediamtx_path_readers和mediamtx_path_publishers两块面板配好 NetworkPolicy 后做一次回归RTSP 拉流、HLS 拉流、API 查询三件事都能走通压测一轮后再定 HPA 的maxReplicas和资源 limits别用拍脑袋的数字上生产【免费下载链接】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），仅供参考