Kubernetes中Init容器设为BestEffort、主容器为Burstable的资源疑问

1. 有效资源请求/限制的计算逻辑纠正 #

你对有效资源的理解存在偏差：

• Init容器的有效请求/限制是所有Init容器中同一资源的最大值，而非取最低值。比如你给出的例子里，InitContainer1为BestEffort（请求/限制均为0），InitContainer2有具体资源值，那么有效Init请求/限制会取InitContainer2的数值，而非0。
• Pod的有效请求/限制是主容器资源总和与有效Init请求/限制两者的较高值，所以你的场景中Pod的有效资源会取主容器总和与InitContainer2数值里的较大者，不会变成BestEffort的0值。主容器的设定值本身不会被Init容器覆盖，Pod的有效资源是调度和QoS计算的依据，而非修改主容器配置的规则。

2. QoS tier的判定逻辑 #

Pod的QoS tier基于Pod的有效请求/限制判定：

• 只有当Pod内所有容器（包括Init容器）都未设置资源请求和限制（全部为BestEffort）时，Pod才会被标记为BestEffort。
• 你的例子中，InitContainer2有具体资源值，主容器为Burstable，Pod的有效资源会满足Burstable的判定条件（有资源请求但未设置限制，或请求值小于限制值），因此整个Pod的QoS为Burstable，不会因单个Init容器是BestEffort而改变。

3. Init容器设为BestEffort的实际问题 #

你的猜测是正确的，主要问题包括：

• 调度风险：BestEffort的Init容器无资源请求，调度器不会为其预留节点资源，可能被调度到资源紧张的节点，导致Init容器因资源不足OOM或无法启动，进而阻塞主容器启动流程。
• 资源管控缺失：无资源限制的Init容器可能无限制占用节点CPU、内存，影响节点上其他Pod的正常运行；同时无法通过Kubernetes的资源监控体系准确追踪其资源使用情况，排查问题时难度更大。

内容的提问来源于stack exchange，提问作者Lucas