Resource requests and limits are foundational to Kubernetes scheduling and stability — misconfigured or absent settings are a very common cause of cluster instability. This guide covers understanding and configuring them correctly.
Requests vs Limits: The Key Distinction
| Setting | Purpose |
|---|---|
| Requests | Guaranteed minimum, used by the scheduler to decide pod placement |
| Limits | Maximum a container can use before being throttled (CPU) or killed (memory) |
Basic Resource Configuration
resources:
requests:
memory: "256Mi"
cpu: "250m"
limits:
memory: "512Mi"
cpu: "500m"250m means 250 millicores, or a quarter of one CPU core — Kubernetes CPU units are fractional, unlike memory which uses standard byte-based units (Mi, Gi).
Why Requests Matter for Scheduling
The scheduler places pods on nodes with sufficient available capacity based on requested (not actual current) resource usage — a pod requesting more than any node can provide will remain unschedulable (Pending status) indefinitely.
Why Missing Requests/Limits Is a Genuine Problem
Without explicit resource specifications, a pod could theoretically consume unbounded resources, potentially starving other pods on the same node — production clusters should generally require explicit resource specifications for every workload.
What Happens When a Container Exceeds Its Memory Limit
The container is OOMKilled (Out Of Memory killed) — visible in kubectl describe pod output, a common cause of the crash-debugging scenario in How to Debug a Crashing Pod in Kubernetes.
What Happens When a Container Exceeds Its CPU Limit
Unlike memory, CPU is throttled (not killed) when exceeding the limit — the container continues running but is artificially slowed, a different (often less immediately obvious) symptom than memory limit violations.
Setting Requests Based on Actual Observed Usage
kubectl top pod POD_NAMERather than guessing, observe actual resource consumption under realistic load (see How to Right-Size Your VPS Based on Actual Usage Data for the general principle, applied here at the pod level) before finalizing request/limit values.
Setting Namespace-Level Resource Quotas
See Kubernetes Namespaces and Resource Quotas Explained — beyond individual pod-level settings, namespace-level quotas prevent any single namespace/team from consuming disproportionate cluster resources.
Using LimitRanges for Default Values
apiVersion: v1
kind: LimitRange
metadata:
name: default-limits
spec:
limits:
- default:
memory: 512Mi
cpu: 500m
defaultRequest:
memory: 256Mi
cpu: 250m
type: ContainerEnsures every container in a namespace gets sensible default resource settings even if the pod definition itself omits them, providing a safety net against unspecified resource configuration.
Balancing Requests and Limits Appropriately
Setting requests too low risks OOM/throttling under real load; setting them too high wastes cluster capacity (the scheduler reserves the requested amount even if actual usage is lower) — find genuine balance based on observed usage patterns, not arbitrary guessing.
Common Errors
Pods stuck Pending with "Insufficient cpu/memory" in events — either your cluster genuinely lacks capacity for the requested resources, or requests are set unreasonably high relative to actual node capacity; verify against actual node resources with kubectl describe nodes.
Continue Reading
- How to Debug a Crashing Pod in Kubernetes
- Kubernetes Namespaces and Resource Quotas Explained
- How to Set Up Horizontal Pod Autoscaling in Kubernetes
Browse more articles in Kubernetes & Container Orchestration.
