大规模生产环境PHP视频文件处理K8s集群调度与弹性伸缩

Kubernetes上跑PHP视频处理，弹性伸缩这件事，说难也难，说简单也简单——关键不在于语言本身，而在于你舍得把“调度”和“干活”拆开。PHP只管调度和元数据管理，真正的编解码、模型推理，必须交给FFmpeg、WAN2.2这类专用Worker。搞清楚了这一点，后面的HPA配置、GPU隔离、存储选择，才能对路。

先说一句：千万别指望PHP自己碰视频帧。很多团队上来就把exec('ffmpeg -i ...')塞进PHP-FPM里跑，结果一个请求卡住好几秒，FPM子进程直接夯死，CPU打满但实际干的活全是阻塞。WAN2.2这类模型更不能直连PHP，显存爆掉就是一眨眼的事。

PHP只负责调度，别让它碰视频帧

• PHP应用应该退到控制平面：接收上传、校验格式、写入任务队列（比如RabbitMQ或Kafka）、返回一个任务ID给前端。
• 真实的转码或视频生成任务，交给独立的Job或Deployment执行。可以用initContainers预加载模型或缓存，主容器只调ffmpeg或python inference.py。
• 如果确实需要PHP做轻量处理（比如截图、抽帧），记得改用proc_open()并设好超时和资源限制，别让它阻塞整个FPM进程池。

HPA扩缩容必须基于真实负载指标

一个常见的坑：kubectl top pod显示CPU 30%，但PHP容器其实是在等FFmpeg子进程结束——这算哪门子有效负载？如果HPA只盯CPU，就会误判：视频任务排队时PHP闲着，HPA不扩容；FFmpeg密集跑时PHP又没占多少CPU，HPA还是没反应。

• 最优方案：用自定义指标。通过Prometheus抓取queue_length（比如Redis的pending count）或task_pending_total（RoadRunner暴露的rr_http_requests_queue_size）。
• 如果只能靠资源指标，给PHP容器设resources.requests.cpu: 200m，同时给FFmpeg Worker的Deployment单独配一个HPA，目标指标用container_cpu_usage_seconds_total。
• 别忘了调整beha vior.scaleUp.stabilizationWindowSeconds。视频任务启动慢——加载模型可能就要10秒以上——把这个值设成60秒，避免刚扩容的Pod因为还没跑出负载就被HPA误判为“无效”而删掉。

GPU资源隔离与节点亲和性必须显式声明

WAN2.2或CUDA加速的FFmpeg需要GPU，但PHP Web层不需要。默认调度下，PHP Pod很可能被挤到GPU节点上，白白浪费资源还抢占显存。

• 给GPU Worker加nodeSelector：nvidia.com/gpu: "1"，并配taints防止PHP Pod误调度过去。
• PHP Deployment反过来加tolerations排除GPU节点，或者直接用nodeAffinity限定到CPU-only节点池。
• 注意StorageClass：视频临时文件要用ReadWriteMany（比如NFS），别用默认的ReadWriteOnce，否则多Worker无法共享输入输出路径。

失败重试与断点续传不能靠PHP自己扛

一个5分钟的视频转码，中途Pod被HPA缩容或者节点故障，PHP如果只记“任务开始”，任务直接就丢了。Kubernetes原生并不保证Job一次成功。

• 用Job而非Pod跑视频任务，设backoffLimit: 3，失败自动重试。
• 任务状态存到外部存储（如MySQL/PostgreSQL），PHP只负责读状态，Worker负责写；千万别用PHP session或本地文件存进度。
• 长任务加activeDeadlineSeconds: 1800（30分钟），防止Worker卡死无限占用GPU。

真正难的不是写YAML，而是厘清边界：PHP管什么、Worker管什么、K8s管什么。视频文件一动就是GB级别，调度错一层，磁盘IO、网络带宽、GPU显存全跟着错。别指望HPA能自动适配所有场景——它只响应你喂给它的指标。喂错了，扩缩容就变成了随机行为。