LiveKit 部署指南：从本地开发到生产集群的完整落地手册

LiveKit 部署指南从本地开发到生产集群的完整落地手册【免费下载链接】livekitEnd-to-end realtime stack for connecting humans and AI项目地址: https://gitcode.com/GitHub_Trending/li/livekitLiveKit 是基于 WebRTC 的高性能实时音视频媒体服务器一套配置就能从单节点跑通到分布式集群。本文带你按落地顺序把 LiveKit 部署从本地开发一路推到生产环境。跑起来之前先备好端口、密钥、Redis 三块地基很多人一上来就纠结配置文件怎么填结果服务起不来。经验之谈先把下面三块地基摆正配置只是水到渠成。端口LiveKit 到底要开哪些口为什么LiveKit 不是只开一个口它同时承担「信令」和「媒体」两类流量端口职责是分开的端口协议作用你能不能放负载均衡 / TLS 后面7880TCP主服务RoomService RTC 信令能生产建议 LB TLS7881TCPWebRTC 的 ICE-over-TCP 回退通道不能必须直接暴露在节点上50000-60000UDPWebRTC 媒体主通道每个客户端占一个不能走四层 TLS需防火墙放行入站6789TCPPrometheus 指标可选内网即可别对外3478/5349UDP/TCP内嵌 TURN 中继可选视 TURN 部署而定一句话结论信令口7880走 LB TLS媒体口UDP 50000-60000必须裸奔且放行入站。这是最容易被运维忽略、也最致命的坑——7881 和 UDP 段一旦藏在 LB 后面UDP 连不通的客户端会静默掉线。多网卡机器上可以用rtc.interfaces/rtc.ips的 include/exclude 过滤掉docker0、lo这类不该暴露的接口避免广告出错误 IP。密钥API Key 与 JWT 怎么配才安全LiveKit 用key:secret的键值对做 JWT 签发与校验可以配多组以便轮转keys: key1: secret1 key2: secret2生产上密钥不要明文写进配置文件提交进仓库用LIVEKIT_KEYS环境变量或 K8s Secret 注入或--key-file指向一个0400权限的文件LiveKit 会强制校验「他人权限必须为 0」否则拒绝启动。开发时可以用livekit-server generate-keys子命令快速生成一组 key/secret。客户端和 Webhook 用的都是同一套 key所以这组 secret 一旦泄露等于全门洞大开轮转策略提前定好。Redis什么时候必须引入分布式判断标准很简单节点数 1就必须上 Redis。单节点不需要 RedisLiveKit 全在进程内闭环配置里留空即可。多节点配上redis.address后LiveKit 自动进入完全分布式模式——客户端连到任意节点都会被路由到同一房间。高可用进一步选Sentinelsentinel_master_namesentinel_addresses或Clustercluster_addresses。注意 Cluster 模式不支持db字段。Redis 里存的是房间状态、节点路由、信令中继这些关键信息它挂了整个集群就瘫了。所以单节点省掉它没问题多节点它必须高可用。三种部署形态怎么选本地、单机容器还是 K8s按「验证 → 交付 → 规模化」的节奏走别一上来就 K8s。形态适用场景是否需要 Redis典型命令本地快速验证打通链路、调 bug否livekit-server --dev容器化单机内网服务、标准化交付视节点数docker run ...K8s 集群多区域生产、自动扩缩是kubectl apply -f本地快速验证一条命令打通链路--dev是最快的上手姿势它同时做了三件事日志级别拉到 debug、切到控制台格式化、开启/debug/pprof。注意官方明确标注它不适合生产——因为不安全。# 源码构建需先把 GOPATH/bin 加入 PATH git clone https://gitcode.com/GitHub_Trending/li/livekit cd livekit ./bootstrap.sh # 安装 mage 并拉取依赖 mage build ./bin/livekit-server --dev--dev模式下如果没给 key会自动用占位的devkey:secret并默认只绑定127.0.0.1/::1回环地址——这正好适合本地自测也避免了误暴露。要跑集成测试、多节点场景参考 test/ 下的用例配一个本地 Redis 即可。容器化单机用 Docker 做标准化交付仓库自带多阶段 Dockerfilegolang阶段编译CGO_ENABLED0纯静态、多架构支持运行阶段只留一个 Alpine 二进制镜像小、攻击面小。docker run -d --name livekit-server \ -p 7880:7880 -p 7881:7881 -p 50000-60000:50000-60000/udp \ -v $(pwd)/config.yaml:/config.yaml \ -e LIVEKIT_CONFIG_BODY$(cat config.yaml) \ livekit/livekit-server --config /config.yaml两个容易踩的点LIVEKIT_CONFIG这个环境变量传的是**配置正文YAML body**而不是文件路径配合--config-body使用容器里不落地文件也能注入配置。用 Docker Compose 编排时Redis 和 LiveKit 放同一网络多节点各自映射不同宿主端口7880/7881 各自的 UDP 段并通过LIVEKIT_REDIS_ADDRESS指向同一 Redis。K8s 集群面向生产的扩展方案K8s 的核心矛盾是UDP 大端口段的暴露。LiveKit 需要 50000-60000 整段 UDP普通 Service 很难优雅映射常见两条路UDP 暴露要么 Pod 用hostNetwork: true配合dnsPolicy: ClusterFirstWithHostNet要么单独拉一个 UDP NodePort Service。媒体流必须点到点直连别指望走 Ingress。配置用 ConfigMap 存 YAML 模板密钥、Redis 密码走 Secret运行时用环境变量注入避免 secret 进 ConfigMap。节点选型多区域生产在配置里设node_selector.kind: regionawareregion坐标把房间就近调度到同区域节点跨区流量和延迟能压下来。资源画像LiveKit 是 CPU 密集型的 SFU默认按每核约 400 轨、每秒 1GB 限速。生产 Pod 建议 requests2C/2Gi、limits 视房间大小上浮到4C-8C别设太紧。LiveKit 生产部署三步走安全、可观测、弹性安全加固非 root、网络策略与密钥管理非 root 运行官方镜像未内置非 root 用户自建镜像时adduserUSER切走或至少加--security-opt no-new-privileges、--cap-drop ALL。网络策略K8s 里用 NetworkPolicy 把入向限定为 Ingress 控制器到 7880/7881出向只放通 Redis 6379对外媒体口单独管理。别裸奔。密钥管理key/secret、Redis 密码、TURN 凭证全部进 Secret配合key_file权限校验杜绝明文入库。接口收敛多网卡主机务必用rtc.interfaces.excludes过滤docker0/lo防止广告出内网/错误 IP 导致客户端连错。可观测接上 Prometheus该盯哪些指标配置里prometheus_port: 6789或prometheus段打开后/metrics暴露关键 Gauge/Counter指标含义何时告警房间 / 参与者 / 轨道数当前活跃规模突增突降判断是否异常掉线节点 CPU / 内存SFU 负载逼近 limit 时扩容收发包量与字节数媒体吞吐与房间规模对不上说明丢包/卡顿NACK / 重传率网络质量持续高企 → 带宽或拥塞问题生产日志建议logging: {level: info, json: true, sample: true}——JSON 便于采集采样避免高频日志把磁盘打满。K8s 里用 ServiceMonitor 挂到 Prometheus端口指向metrics6789。弹性扩缩容HPA 到底怎么设LiveKit 是 CPU 密集型HPA 主看CPU 利用率内存作兜底minReplicas至少 2多节点必须有 Redis 兜状态maxReplicas按容量规划给足。CPU 目标 70% 左右、内存 80%scaleUp 可以激进每周期 2 Pod / 50%scaleDown 要保守长周期 -1避免房间被频繁迁移抖动。注意扩出来的新 Pod 要等它注册进 Redis、被 node selector 选中后才接新房间所以扩容不是即时的别指望秒级弹性。常见坑与快速排障端口、连不上、UDP 打不通症状大概率原因快速定位服务起不来日志报 key 权限key_file他人可读文件chmod 0400他人权限必须为 0客户端连上信令但没画面UDP 段没放行 / 被 LB 挡了检查防火墙 50000-60000 入站7881/UDP 不能藏 LB 后连了但一直黑屏公网 IP 没发现对云环境开rtc.use_external_ip: trueSTUN 探测真实出口 IP端口冲突7880/7881 被占lsof -i :7880找占用进程浏览器侧排查ICE/媒体流状态chrome://webrtc-internals看 connectionState 与统计排障顺序建议先信令后媒体——先用curl打通 7880 确认服务活着再查 UDP/7881 是否真正可达最后才怀疑客户端。别一上来就怀疑代码。结语一张落地清单端口7880 走 LBTLS7881 与 UDP 50000-60000 直连放行。密钥多组key:secret生产用 Secret /LIVEKIT_KEYS注入key_file权限 0400。Redis多节点必配高可用选 Sentinel 或 Cluster。部署节奏--dev本地验证 → Docker 单机交付 → K8s 集群扩容。生产三件事非 root 网络策略、Prometheus 指标、CPU 导向的 HPA。下一步建议先在本机--dev跑通一个房间再上单机容器做交付最后按 K8s 方案扩到多节点配置细节对照 官方配置示例 逐项核对。把地基打牢剩下的就是规模化了。【免费下载链接】livekitEnd-to-end realtime stack for connecting humans and AI项目地址: https://gitcode.com/GitHub_Trending/li/livekit创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考