Bin Packer: Requests & Limits

Requests decide where a pod lands. Limits and node pressure decide when it gets hurt.

Requests determine scheduling fit; CPU limits throttle, memory limits can trigger OOM kills, and node memory pressure can cause eviction. Queue pods, let the scheduler place them, then turn up the load.

Load1x

CPU reserved 600m30%

CPU used 1000m50%

Σ limits 500m + unbounded (overcommitted)

Mem reserved 384Mi19%

Mem used 650Mi32%

Σ limits 256Mi + unbounded (overcommitted)

CPU reserved 550m28%

CPU used 600m30%

Σ limits 500m + unbounded (overcommitted)

Mem reserved 512Mi25%

Mem used 1630Mi80%

Σ limits 512Mi + unbounded (overcommitted)

CPU reserved 750m38%

CPU used 1200m60%

Σ limits 1000m + unbounded (overcommitted)

Mem reserved 384Mi19%

Mem used 480Mi23%

Σ limits 768Mi + unbounded (overcommitted)

Not scheduled (0)

Every pod fits somewhere. Queue a pod with a big request to see Pending.

Select a pod or a node to see its requests, limits, demand and why it ended up where it did.

Custom pod

Burstable

Set cpu request

CPU request250m

Set cpu limit

CPU limit500m

Set memory request

Memory request256Mi

Set memory limit(unset, no cap)

Demand at 1x load (what the app actually wants, independent of requests)

CPU demand200m

Memory demand300Mi

Effective requests: 250m, 256Mi

How this model simplifies

One container per pod, restartPolicy: Always, owned by a Deployment, all at equal priority. This is a snapshot, not a timeline.

OOM is instant here. The real kernel kills the container after memory goes over its limit, and the kubelet restarts it.

Eviction follows the kubelet's order: pods using more than their memory request first, then the largest overage above request. It is not sorted by QoS class directly.

Not modelled: allocatable vs capacity, CPU shares under contention, priority and preemption, taints and affinity.