k8s Flashcards
← Back to blog
SchedulingResourcesPendingCKAD

Resource Requests vs Limits: What the Scheduler Actually Sees

You set a 4 CPU limit but the pod stays Pending — limits do not reserve capacity. How requests, limits, and QoS affect scheduling and eviction.

1 min read
resources:
  limits:
    cpu: "4"
    memory: 8Gi
  requests:
    cpu: 100m
    memory: 128Mi

The pod is Pending. Node has 2 CPUs free. Confusing?

Requests = scheduling contract

The scheduler sums requests across pods on a node and compares to allocatable capacity. It does not schedule based on limits.

High limits with tiny requests pack many pods onto a node until real usage causes throttling or OOM — but scheduling succeeded.

Opposite problem:

requests:
  cpu: "8"

On a 4-CPU node → FailedScheduling: Insufficient cpu in Events.

Limits = runtime cap

  • CPU limit: CFS throttling when usage exceeds limit
  • Memory limit: OOMKill when exceeded

Limits do not help you get a slot on the node.

QoS classes (eviction order)

ClassWhen
**Guaranteed**requests = limits (all containers)
**Burstable**requests set, limits may differ
**BestEffort**no requests/limits

Under memory pressure, BestEffort pods evict first, then Burstable, then Guaranteed.

HPA needs requests

Horizontal Pod Autoscaler CPU metric uses actual / request. Missing CPU requests → unknown metrics → no scale.

First step when Pending

kubectl describe pod <name> | grep -A5 Events

Look for Insufficient cpu/memory — then lower requests or add nodes, not tweak limits alone.

Practice in Scheduling & Resources on Decision Trainer.