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

Kubernetes中PHP视频处理弹性伸缩的关键是职责分离：PHP仅作调度与元数据管理，真实编解码由FFmpeg或WAN2.2等专用Worker执行；HPA需基于队列长度等自定义指标而非CPU，并配合GPU节点亲和性、ReadWriteMany存储及Job重试机制保障可靠性。

PHP本身不直接处理视频编解码，大规模视频文件处理必须绕开PHP进程——把它当成调度器、元数据处理器和任务分发器，真干活的得交给FFmpeg、WAN2.2或专用Worker。Kubernetes里做弹性伸缩，关键不是“PHP能不能跑视频”，而是“怎么让PHP触发的任务链能随负载自动扩缩”。

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

常见错误是把exec('ffmpeg -i ...')塞进PHP-FPM里跑：单次请求卡住几秒，FPM子进程夯死，CPU打满但实际没干视频活。WAN2.2这类模型更不能直连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
• 别忽略behavior.scaleUp.stabilizationWindowSeconds：视频任务启动慢（加载模型要10s+），设成60秒，避免刚起Pod就被HPA误判为“无效”而删掉

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

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

立即学习“PHP免费学习笔记（深入）”；

• 给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自动适配所有场景，它只响应你喂给它的指标——喂错指标，扩缩容就变成随机行为。