PHP工作负载调度关键在于Pod而非框架，需按长时服务（Deployment+nodeAffinity）与短时任务（Job+podAntiAffinity）分类施策，结合真实资源请求、柔性亲和策略及Service/Ingress流量控制实现可预测、可伸缩、可隔离运行。
PHP框架本身不参与Kubernetes调度，真正需要调度的是运行PHP应用的Pod。云原生部署的关键，是让PHP工作负载（如Web服务、任务处理器）在K8s中可预测、可伸缩、可隔离地运行——这依赖于合理的资源声明、亲和性策略、服务拓扑与控制器选型，而非框架代码本身。
明确PHP工作负载类型再定调度策略
PHP在K8s中通常承担两类角色：长时服务（如API网关、Swoole常驻进程）和短时任务（如上传后触发的元数据处理、异步通知）。二者调度逻辑完全不同：
- Web类Pod（Deployment）需稳定驻留、支持滚动更新，适合用
nodeAffinity绑定CPU优化型节点，避免混跑GPU任务 - 任务类Pod（Job或CronJob）应设
restartPolicy: OnFailure，配合ttlSecondsAfterFinished自动清理，并通过podAntiAffinity确保同任务不挤在同一节点 - 若使用RoadRunner或Swoole做常驻服务，需在Deployment中配置
livenessProbe和readinessProbe指向其管理端口（如/health），避免误杀存活进程
用nodeAffinity替代nodeSelector实现柔性约束
nodeSelector太刚性，一个标签缺失就卡在Pending；生产环境推荐用nodeAffinity表达更健壮的落点逻辑：
- 强制PHP Web Pod只跑在
role=php-worker且disk=ssd的节点上，但允许其中任意一个条件不满足时降级调度（用preferredDuringSchedulingIgnoredDuringExecution） - 对关键服务加
podAntiAffinity，比如让三个API实例尽量分散在不同可用区：topologyKey: topology.kubernetes.io/zone - 若集群含Spot节点，给非关键PHP任务加
nodeAffinity匹配lifecycle=spot，同时配tolerations容忍spot-only污点
资源请求与限制必须真实反映PHP行为
PHP-FPM或Swoole的内存波动大，仅靠resources.limits.memory易OOM Kill；CPU限制过严又会导致并发下降。应结合运行时特征设定：
立即学习“PHP免费学习笔记（深入）”；
- FPM模式：按最大worker数×平均单worker内存估算，例如
pm.max_children: 20× 30MB ≈600Mi，并设requests.cpu: 100m保底调度公平性 - Swoole协程模式：内存更稳定，可收紧
limits.memory，但需预留额外100–200MB应对峰值序列化开销 - 所有PHP容器禁用
resources.limits.cpu（除非确需硬限频），改用requests.cpu保障QoS等级为Burstable即可
Service与Ingress配置影响实际流量调度
K8s层的调度终点是Pod，但用户请求最终落到哪台PHP实例，由Service和Ingress共同决定：
- ClusterIP Service默认用iptables或ipvs轮询，若PHP应用有会话粘性需求（如未接入Redis Session），应启用
sessionAffinity: ClientIP并设sessionAffinityConfig.clientIP.timeoutSeconds - Ingress控制器（如Nginx Ingress）需开启
upstream-hash-by或JWT claim哈希，实现业务维度的负载均衡，避免单用户请求全打到同一Pod - 对外暴露PHP服务时，优先用Ingress而非LoadBalancer，便于统一TLS终止、WAF集成与灰度路由
