Init Container 中运行 composer install 必须设 CPU/memory 限制，因其解压、校验、生成 autoload 等操作资源消耗高（CPU 峰值 0.8–1.2 核，内存峰值 350–600 MB），未设 limits 易被 OOM Killer 杀掉或卡住；Init Container 资源独立于主容器，需单独配置 requests/limits，推荐 limits.cpu: "1"、limits.memory: "768Mi"，若含 rm -rf vendor 清理逻辑则内存至少 "896Mi"。
Init Container 里跑 composer install 为什么必须设 CPU/memory 限制
不设限制的 composer install 在 Init Container 中极易因资源耗尽被 OOM Killer 杀掉或卡在 autoloader 生成阶段，尤其当 vendor/ 较大（>100MB）或含大量 dev 依赖时。Kubernetes 默认不限制 Init Container 资源，但它的执行时间、内存峰值和 CPU 占用远超普通容器——它要解压、校验、写入、生成 classmap，不是轻量操作。
- 没设
limits.memory：PHP 进程可能申请几百 MB 内存，触发节点级 OOM，整个 Pod 启动失败 - 没设
limits.cpu：Composer 并行下载/解压会打满单核，阻塞其他 Init Container 或主容器调度 - 只设
requests不设limits：调度器能分配资源，但运行时无硬性约束，仍可能失控
composer install 的典型资源消耗与推荐限额值
实测一个中等规模 PHP 应用（composer.lock 约 200 行，含 Laravel + Symfony 组件），composer install --no-dev --prefer-dist --optimize-autoloader 的资源表现如下：
- CPU 峰值：0.8–1.2 核（集中在 zip 解压和 classmap 生成阶段）
- 内存峰值：350–600 MB（取决于 autoload 生成策略和依赖数量）
- 执行时间：8–25 秒（受镜像层缓存、网络延迟、emptyDir 性能影响）
推荐 Init Container 的资源设置：
resources:
limits:
cpu: "1"
memory: "768Mi"
requests:
cpu: "0.3"
memory: "384Mi"
注意：memory 必须用 Mi（二进制单位），不能写 M；cpu 用小数或整数均可，但 "1" 比 1 更安全（避免 YAML 类型解析歧义）。
为什么不能复用主容器的资源配额
Init Container 和主容器的资源是独立申请、独立限制的。即使主容器只配了 cpu: "0.5"，Init Container 仍可申请 cpu: "1" —— 它们不在同一 cgroup 下，也不共享 quota。常见错误是直接复制主容器配置到 Init Container，结果：
-
composer install因 CPU 不足被 throttled，执行超时（默认initContainer超时为 5 分钟，但实际卡住 2 分钟后就不可逆失败） - 内存不足导致
proc_open()失败或file_put_contents()写入中断，留下半截vendor/autoload.php - 资源请求过低，Pod 卡在
Pending状态，调度器找不到满足requests的节点
结合幂等清理逻辑的资源安全边界
前面提到的 rm -rf vendor/ && composer install ... 流程，资源消耗比单纯 composer install 更高——因为要先递归删除、再重建。实测该组合操作内存峰值比纯 install 高 20–30%。所以：
- 如果用了清理逻辑，
limits.memory至少设为"896Mi"（而非"768Mi"） - 避免在
emptyDir上挂载过小 volume（如sizeLimit: "512Mi"），否则rm -rf可能失败或触发磁盘配额告警 - 不要给 Init Container 加
livenessProbe或readinessProbe：它不支持健康检查，只会报错
最易被忽略的一点：资源限制生效前提是 Init Container 的镜像里 PHP 和 Composer 版本稳定。如果用 php:latest 或 composer/composer:latest-bin，某次更新可能让内存峰值突然上涨 100MB，旧限额就不再安全。
