Fig 10Requests, limits & QoSBurst, spike, leak or add a pod belowrequested 1.5/4 CPU, 3/8 GiB
Pod
QoS class
CPU req / lim / use
Mem GiB req / lim / use
Restarts
State
resources: # api: Burstable (requests below limits)
requests: { cpu: 500m, memory: 1Gi } # what the scheduler reserves
limits: { cpu: "1", memory: 3Gi } # CPU above: throttled · memory above: OOMKilled
# Guaranteed: requests == limits for every container · BestEffort: no requests or limits at all
Dashed tick: the request, what the scheduler reservesBright cap: the limit; the node tower's bright line is the sum of requestsRed fill: throttled CPU, memory near its limit, or a node under memory pressureRequests are what the scheduler reserves on a node; it places a pod only where the sum of requests still fits, whatever the node is really using, so a big pod can stay Pending on an idle node. Limits cap a running container: CPU above the limit is throttled, while memory above the limit gets the container OOM-killed and restarted. Requests and limits together set the QoS class: Guaranteed when they are equal, Burstable when requests are lower, BestEffort when there are none. When a node runs short of memory, the kubelet evicts BestEffort pods first, then Burstable pods using more than they requested, and Guaranteed pods last.