企业官网建设流程全解析

LiveKit 部署三步走：一条 Docker 命令到生产可用的 WebRTC 服务器

【免费下载链接】livekitEnd-to-end realtime stack for connecting humans and AI项目地址: https://gitcode.com/GitHub_Trending/li/livekit

LiveKit 是开源的 WebRTC 实时音视频媒体服务器。这篇是 LiveKit 部署实战：先用一条 docker 命令让它活起来，再给出单机、双节点 + Redis、Kubernetes 三种场景各自的 LiveKit 配置最小改动，最后附上线清单和故障速查。

部署前先花 5 分钟核对端口与依赖

动手前你只需要核对三样东西：2 个 TCP 端口、1 段 UDP 范围、1 个 Redis（单机可免）。这就是 WebRTC 服务器搭建的完整网络清单：

一条命令确认本机主端口空闲：

ss -lntup | grep -E ':(7880|7881)' || echo "7880/7881 空闲"

||之后那行没输出说明端口没人占。没有现成 Redis 的话，先docker run -d -p 6379:6379 redis:7-alpine拉一个，后面场景二要用。

用最快的 docker 命令跑通 LiveKit 并两步验活

下面这条命令 30 秒内让 LiveKit 跑起来，唯一要带的是LIVEKIT_KEYS——服务器用它签访问令牌（JWT，客户端拿它换房间入会资格）：

docker run -d --name livekit \ -p 7880:7880 -p 7881:7881 \ -p 50000-60000:50000-60000/udp \ -e LIVEKIT_KEYS="devkey:secret" \ livekit/livekit-server

两个验活信号，都来自服务端自己的行为：

curl -s http://127.0.0.1:7880/ # 期望输出: OK docker logs livekit 2>&1 | grep -m1 "starting LiveKit server"

第一个是健康检查路径/，节点正常返回OK，初始化未完成时返回Not Ready（实现见 pkg/service/server.go 的healthCheck）；第二个日志关键字里带节点 ID 和实际占用的 ICE 端口范围。两条都命中即算跑通；curl 直接 connection refused，先查容器端口映射。

按场景挑一套最小 LiveKit 配置

配置文件全文 400 多行，但真正要动手的只有下面几处，其余参数保持默认即可，完整字段注释以仓库根目录的 config-sample.yaml 为准。

场景一 · 单机演示：只改三处配置就能开演

给产品评审或内部试用时，改三处：换密钥、日志调 debug、其余全默认：

keys: devkey: secret rtc: port_range_start: 50000 port_range_end: 60000 tcp_port: 7881 logging: level: debug

livekit-server --config dev.yaml启动（容器场景用-v把文件挂进去）。三点说明：

• keys用官方示例值devkey:secret，客户端 SDK 内置同一对默认值，浏览器演示页可免配置直接入会；
• rtc两行就是默认值，写出来只是让你确认 UDP 区间和 TCP 回退端口与上面的端口清单一致；
• 纯本地跑可以跳过配置文件直接livekit-server --dev，它等价于 debug 日志 +devkey:secret+ 只绑 127.0.0.1（见 cmd/server/main.go 的getConfig）。

想让空房间自动关闭就加一行room.empty_timeout: 300（秒），不加也行。

场景二 · 双节点 + Redis：加一个配置块，房间就能跨机漫游

开始跨两台机器后，核心问题是：客户端连到节点 A，房间却在节点 B 上，谁来接？答案是 Redis——每个节点启动时把自己注册进 Redis（对应 pkg/service/server.go 的RegisterNode），接请求的节点会把参与者路由到房间所在的节点，两台机器因此看到同一份房间列表。

所以全部改动就是给两台节点配上同一个redis块，两份配置几乎相同：

keys: ak_prod: <32位随机secret> redis: address: 10.0.0.5:6379 password: <redis密码> rtc: port_range_start: 50000 port_range_end: 60000 use_external_ip: true prometheus: port: 6789

四处要点逐条解释：

• redis.address必须指向同一个实例，第二台节点只改 keys 和 Redis 密码即可，节点 ID 自动生成，不用手工编号；
• use_external_ip: true让节点通过 STUN 发现自己的公网 IP 再广播给客户端——云上 ECS/GCE 默认拿到的是内网 IP，客户端够不着，不开这行 ICE 必挂；
• 两节点keys必须一致，JWT 校验是无状态的，密钥对不上第二台会直接拒签；
• prometheus.port: 6789开启指标端口，每台各自暴露/metrics，Prometheus 同时抓两台。

网络侧别忘：两台机器的安全组都要开 50000-60000/UDP。媒体流是客户端与节点直连，任何一台漏开都会出现“一半连接没画面”。

场景三 · Kubernetes 生产：TLS、HPA、探针三件套最小清单

这是 LiveKit kubernetes 部署的骨架：探针 6 行、HPA 8 行，入口一句话，再配一个集群内的 Redis。探针复用前面的/路径，正常返回OK、异常返回406 Not Ready，正好给 liveness 用：

containers: - name: livekit image: livekit/livekit-server:latest ports: [{containerPort: 7880}, {containerPort: 7881}] livenessProbe: httpGet: {path: /, port: 7880} initialDelaySeconds: 10 periodSeconds: 10 readinessProbe: httpGet: {path: /, port: 7880} periodSeconds: 5

TLS 入口只有一条硬规则：Ingress 或 L4 负载均衡把 443 指到 7880 并允许 WebSocket 升级（信令走 WebSocket）；7881 不能过 TLS，用 NodePort 直接暴露。UDP 范围最省事的方案是给 Pod 设hostNetwork: true，容器直接用宿主机 50000-60000，Service 只管 TCP。

HPA 按 CPU 缩，阈值先取 70%：

apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: livekit spec: scaleTargetRef: {apiVersion: apps/v1, kind: Deployment, name: livekit} minReplicas: 2 maxReplicas: 8 metrics: - type: Resource resource: {name: cpu, target: {type: Utilization, averageUtilization: 70}}

最后提醒：多副本没有 Redis 等于没部署——节点互相看不见房间，HPA 扩出来的副本不会接活。密钥放 Secret 经LIVEKIT_KEYS注入，轮换时改 Secret 滚动 Pod。Redis 规模再上台阶，才考虑换成 cluster 模式（配置里改填cluster_addresses）。

上线前把端口、TLS、密钥、监控、日志五项打勾

• 端口：7880/7881 TCP 与 50000-60000 UDP 在安全组放行，并在节点上用ss -lnt交叉确认监听
• TLS：7880 在 LB 后走 443；7881 在节点上直暴露，不经 TLS
• 密钥：用livekit-server generate-keys生成强密钥对，生产不出现devkey:secret；轮换流程写进文档
• 监控：prometheus.port: 6789，/metrics已加入 Prometheus 抓取目标
• 日志：level: info、json: true、sample: true，日志采集链路已接入

LiveKit 部署后最常见的三个现象这样排查

现场问题九成是下面三条之一，先对现象，再执行处置。

1. 现象：客户端连接超时，公网 curl 7880 不通 →原因：防火墙未放行，或容器/K8s Service 没转发该端口 →处置：先查安全组，再在节点执行livekit-server ports --config <你的配置>核对实际占用的端口，最后查-p映射或 Service 定义。
2. 现象：能连上但 ICE 协商失败、无媒体流 →原因：UDP 50000-60000 未放行，或节点公网 IP 对客户端不可达（云上内网 IP 最常见）→处置：放行 UDP 段；云上加use_external_ip: true；浏览器开chrome://webrtc-internals看哪一组 candidate 失败。
3. 现象：双节点下 A 能看到房间、B 返回 404 →原因：两台redis.address不是同一实例，或 Redis 密码错导致注册失败（启动日志里有could not字样）→处置：核对两份配置，redis-cli -h 10.0.0.5 ping应回 PONG。

结语：拿真实客户端进房

单机配置演示已够用，扩容时只补 redis 块和探针三件套。下一步：用客户端 SDK 进一个真实房间，发一帧视频。

【免费下载链接】livekitEnd-to-end realtime stack for connecting humans and AI项目地址: https://gitcode.com/GitHub_Trending/li/livekit