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