在 Kubernetes 上做视频编码：把媒体流水线跑在 K8s 上究竟需要什么
内容提要
文章讨论如何在Kubernetes上稳定运行FFmpeg/GStreamer直播编码，核心建议包括：将会话控制与媒体执行分离，由外部服务负责准入与分派；按实测编码配置设定资源请求；依据队列深度等媒体工作量进行扩缩容；用启动、就绪、存活探针分别衡量初始化、可接活和真实帧进度；在分片边界实现受控替换与幂等恢复；监控编码耗时、截止时间错过等媒体指标，而非只看CPU。
延伸解读
控制面与执行面分离：避免编码器变成微型调度器
文章强调，把准入、放置和策略决策放在编码器进程之外，由轻量控制服务校验流、选择档位阶梯并分派有边界的契约。这样做的好处是，每个媒体容器不必承担调度职责，同时获得一个干净的位置在容量不足时快速拒绝工作。直播场景中，接纳一个无法按时完成任务的会话，往往比快速拒绝更糟，因为迟到的分片会引发下游重试和观众可见的不稳定。
资源请求来自实测包络，而非默认值复制
文章指出，资源请求应基于实测的编码配置档，而不是把默认值复制到每个 Pod。不同编解码器、分辨率、帧率和滤镜链对 CPU、内存带宽和加速器的需求差异很大，因此需要为每种组合建立资源包络，再翻译成 requests 和 limits。Kubernetes 用请求做放置，设备插件暴露 GPU 等加速器，独立节点池和亲和性规则有助于保持 CPU 与加速器工作负载的可预测性。
扩缩容看等待中的媒体工作，而非横向 CPU
文章认为，对新的直播活动而言，横向 CPU 利用率是滞后信号。更有用的输入包括准入队列深度、待启动流数量、聚合每秒像素数以及接近截止时间的分片数量。事件驱动自动扩缩器可以把这些指标转化为副本需求，但指标必须真实代表媒体工作量。直播层级应避免缩容到零，保留热备下限，并小心缩容，不要因为队列变安静就终止进行到一半的长时间会话。
探针要回答不同问题，替换要在分片边界受控进行
文章建议让启动、就绪和存活探针分别衡量初始化、可接活和真实帧进度，避免重启尚未有用的慢启动编码器，也避免把工作路由给活着但不再产出输出的进程。替换实例应在明确分片边界续接，持久化最后已提交序号，让上传幂等，防止两个工作进程发布同一分片。终止时停止接新工作、排空至安全边界，并让重试受播放截止时间约束，无法及时恢复时有意降级而非全阶梯失败。
Q&A
为什么说直播编码器不是普通的无状态Web工作进程？
直播编码器消费持续的流，维护编解码器状态，并必须在播放缓冲区察觉之前输出每一路档位的画面。一个Pod在集群眼中可以是健康的，同时却在不可逆地落后。
在Kubernetes上运行直播编码，为什么要将会话控制与媒体执行分离？
分离后，准入、放置和策略决策由外部轻量控制服务负责，编码器Pod只接收有边界的契约（流或分片、档位阶梯、帧率、输出目标、截止时间）。这避免每个媒体容器变成小调度器，并能在容量不足时快速拒绝工作，防止迟到分片引发重试和观众可见的不稳定。
如何为编码器Pod设置资源请求？
资源请求应来自实测的编码配置档，而不是复制默认值。为每种编解码器、分辨率、帧率、预设和滤镜链建立资源包络，再翻译成Pod的requests和limits。不同档位（如1080p AVC与4K HEVC）需求不同。
直播编码场景下，应该依据什么指标进行扩缩容？
应依据“等待中的工作”扩缩容，如准入队列深度、待启动的流数量、聚合的每秒像素数、接近截止时间的分片数量。CPU利用率是滞后信号。可使用KEDA等事件驱动自动扩缩器，但指标必须真实代表媒体工作量。
Kubernetes的启动、就绪、存活探针在编码器上应分别衡量什么？
启动探针应允许编解码器初始化、硬件上下文创建和输入协商完成；就绪探针应意味着进程能接受或继续已分派的媒体工作，而不仅仅是HTTP端口有响应；存活探针应检测真正的停滞，例如在限定时间间隔内没有帧或分片进度。
编码器Pod被替换时，如何实现受控恢复？
设计会话状态时，让替换实例能在明确边界处续接。基于分片的输出提供检查点：持久化最后已提交的序号，让上传具备幂等性，防止两个工作进程发布同一个分片。终止过程中，停止接受新工作，排空至安全边界，并通过就绪探针暴露该状态。重试必须受播放截止时间约束，无法及时恢复时有意降级（如保留更少档位）。
除了CPU和内存，还应该监控哪些媒体层面的指标？
应加入媒体层面的服务指标：每帧或每分片的编码耗时、编码前的排队延迟、输出连续性、时间戳漂移、丢帧、截止时间错过次数，以及各档位的失败率。并将这些指标与Pod放置位置、节点类型、编解码器设置和输入特征关联起来。
