Resource Requests, Limits and Quotas

A request is what the scheduler uses to place a Pod — it only schedules a Pod onto a node with at least that much spare capacity. A limit is a hard ceiling: CPU usage above the limit gets throttled, while memory usage above the limit can get the container killed by the out-of-memory handler. These two numbers, present or absent per container, decide a Pod's Quality of Service (QoS) class. Guaranteed requires every container to set both a CPU and a memory request equal to its limit. Burstable covers anything that doesn't meet Guaranteed but sets at least one request or limit somewhere. BestEffort is a Pod where no container sets any request or limit at all.

QoS class decides eviction order when a node runs low on resources: BestEffort Pods are evicted first, then Burstable, and Guaranteed Pods last.

resources:
  requests:
    cpu: "250m"
    memory: "256Mi"
  limits:
    cpu: "250m"
    memory: "256Mi"

A ResourceQuota is a namespace-scoped object that caps total resource consumption — or total object counts, such as the number of Pods or Services — across everything in that namespace. A namespace-wide quirk worth knowing: once a namespace has a ResourceQuota covering compute resources (CPU or memory), every Pod submitted to that namespace must specify its own requests and limits, or it is rejected outright at admission — the quota can't account for a Pod whose consumption it can't measure.

A LimitRange is a different, complementary namespace-scoped object: it supplies default requests and limits for any container that omits them, and can also enforce per-container minimum and maximum bounds. Where a ResourceQuota caps totals, a LimitRange fills gaps and bounds individual containers.