Composer镜像不参与HPA扩缩，真正需扩缩的是运行其构建产物的PHP Pod；HPA仅监控运行时Pod指标，要求显式配置resources.requests并确保Metrics Server正常采集数据。
HPA 不会、也不能对 Composer 构建阶段做扩缩
Composer 运行在构建期（Build-time），通常发生在 CI/CD 流水线或 Docker build 阶段，不是运行在 Pod 里的长期进程。HPA 只监控运行中 Pod 的指标（如 cpu、memory、自定义指标），它看不到、也管不了构建动作。
常见误解是：“我用了 Composer，所以得按 Composer 的并发数来扩缩”。实际上：
- Composer install 是一次性动作，完成即退出，不会持续占用 CPU 或内存
- Pod 启动后真正干活的是
php-fpm、nginx或artisan serve这类长期进程 - HPA 的 targetRef 必须指向 Deployment/StatefulSet 等可伸缩资源，不是指向某个命令或工具
PHP 应用 Pod 的 HPA 配置关键点
要让基于 Composer 的 PHP 应用支持 HPA，核心是确保 Pod 模板里正确声明了资源请求，并且 Metrics Server 能采集到有效指标：
-
resources.requests.cpu和resources.requests.memory必须显式设置，否则 HPA 无法计算利用率百分比 - 避免只设
limits不设requests—— 这会导致 HPA 计算时分母为 0，报错failed to get cpu utilization: missing request for cpu - 如果用
memory做指标，注意 PHP 的内存释放行为：脚本执行完不一定立刻归还内存给 OS，memory.workingset比memory.usage更反映真实压力 - 对于高并发短连接场景（如 API 服务），CPU 利用率比内存更稳定；对长耗时脚本（如报表导出），内存更容易成为瓶颈
为什么不能用 Composer 的 exit code 或日志行数做 HPA 指标？
有人想把 Composer 执行失败次数、依赖安装耗时等作为扩缩依据，这在技术上不可行：
- HPA 不解析容器日志，也不监听 exit code；它只消费 metrics-server 或 custom-metrics-apiserver 提供的聚合数值
- 即使你用 Prometheus 抓到了
composer_install_duration_seconds_count这类指标，它也是离散事件，没有连续时间序列，HPA 无法据此计算“当前负载” - 这类指标更适合告警（Alertmanager）或调试，而不是驱动扩缩决策
真要基于构建行为联动伸缩，得走另一条路：用 Argo Workflows 或 Tekton 触发构建任务，再通过 post-hook 更新下游 Deployment 的 replicas —— 但这属于编排层联动，不是 HPA。
SDXL 类服务的教训同样适用于 PHP 应用
就像 SDXL 1.0 部署时强调的那样，GPU 密集型任务和 PHP 应用都面临相同问题：单实例吞吐有硬上限。但区别在于：
- SDXL 依赖 GPU 显存和推理延迟，常需基于
custom.metrics.k8s.io/v1beta2暴露gpu.memory.used或queue_length - PHP 应用一般跑在 CPU 上，优先用
resource指标；若需更精细控制（比如按请求数），就得接入prometheus-adapter，把http_requests_total转成 HPA 可读格式 - 无论哪种，都要确认
kubectl get --raw "/apis/metrics.k8s.io/v1beta1/namespaces/default/pods"能返回数据，否则 HPA 会卡在unknown状态
最容易被忽略的一点：HPA 默认每 15 秒拉一次指标，但 Pod 启动后前 60 秒默认不参与扩缩（由 initialDelaySeconds 和 readinessProbe 决定）。如果你的 PHP 应用启动慢（比如要预热 OPcache、加载大配置），HPA 可能在它还没 ready 时就误判为“空闲”，导致过早缩容。
