Kubernetes resource configuration controls two different moments in a workload's life. Requests help the scheduler decide where a Pod can fit and influence resource sharing under contention. Limits are passed to the container runtime for enforcement. Treating a request as a hard cap—or a limit as guaranteed capacity—leads to unschedulable Pods, unpredictable latency, or memory terminations.
Requests and limits answer different questions
| Setting | Primary role | Important consequence |
|---|---|---|
requests.cpu | Scheduling demand and CPU weight under contention | A container may use more CPU than its request when capacity is available. |
limits.cpu | CPU-time ceiling | The kernel makes the cgroup wait when it exceeds the allowed CPU time. |
requests.memory | Scheduling demand and a signal for memory management | Usage above the request can increase eviction risk during node pressure. |
limits.memory | Memory ceiling for the cgroup | The kernel may terminate a process through the OOM mechanism when the limit is exceeded. |
A request is not a reservation of a permanently idle physical slice. If a node has spare capacity, a container can use more than its request. The scheduler still evaluates declared requests when placing new Pods, because relying on momentary low usage would overpack a node before a predictable peak.
Read CPU and memory units correctly
One Kubernetes CPU is one physical core or one virtual core, depending on the node. 500m means 500 millicpu, or half a CPU. CPU quantities can be fractional.
Memory is measured in bytes and supports suffixes such as Mi and Gi. Case matters. 400Mi is roughly 400 mebibytes, while 400m is four-tenths of a byte and is almost certainly a mistake. Keep CPU millicpu and memory units visually distinct during review.
A clear container resource budget
resources:
requests:
cpu: 250m
memory: 256Mi
limits:
cpu: 500m
memory: 512MiThis container asks the scheduler to plan for 0.25 CPU and 256 MiB of memory. Its CPU use is capped at 0.5 CPU, and its memory cgroup is limited to 512 MiB. These numbers are an example, not a universal recommendation. Derive them from representative load, runtime overhead, startup peaks, garbage collection, and safety margins.
If a limit is set without a request and no admission policy supplies a request, Kubernetes may copy the limit as the request for that resource. Relying on that default can hide intent. Declare both values or enforce a documented namespace policy.
Why CPU pressure and memory pressure look different
CPU is compressible: a process can wait and continue later. A CPU limit creates a hard ceiling on CPU time. Under sustained demand, that waiting can appear as increased response latency, request queues, and probe timeouts. Kubernetes does not normally kill a container merely because it wants more CPU than its limit.
Memory is not handled the same way. Memory-limit enforcement is reactive. If a process attempts to use memory beyond the cgroup limit, the kernel's out-of-memory subsystem can terminate a process. When the main process is killed, Kubernetes commonly reports OOMKilled and restarts the container according to policy.
A Pod can also be evicted during node memory pressure, especially when it consumes beyond its request. OOM killing and eviction are different events. Inspect the terminated container state and Pod events rather than labeling every disappearance an OOM.
Diagnose with status, events, and trends
kubectl top pod api-7d8f9c6b5c-abcde
kubectl describe pod api-7d8f9c6b5c-abcde
kubectl get pod api-7d8f9c6b5c-abcde \
-o jsonpath='{.status.containerStatuses[*].lastState.terminated.reason}'kubectl top is a current sample when a metrics pipeline is available, not a capacity plan. Combine percentiles over representative traffic with restarts, OOM events, CPU throttling metrics, queue depth, latency, and garbage-collection behavior. Averages hide short memory spikes and bursty CPU demand.
An unschedulable Pod needs a different investigation. kubectl describe pod can show that no node has sufficient unrequested CPU or memory according to scheduler accounting. Reducing a request merely to make placement succeed can recreate the problem as runtime contention.
A measurement-first tuning loop
- Collect workload metrics during startup, steady state, and peak traffic.
- Set requests near a defensible operating requirement so the scheduler plans realistic capacity.
- Set memory limits with room for expected peaks and runtime behavior.
- Evaluate whether a CPU limit protects neighbors or creates unacceptable latency for this workload.
- Load test, deploy gradually, and alert on restarts, OOM events, saturation, and tail latency.
- Revisit the values when code, traffic, node types, or runtime versions change.
Common pitfalls
- Writing
memory: 400mwhen400Miwas intended. - Assuming a request prevents use above that value.
- Assuming CPU-limit excess produces
OOMKilled. - Using one dashboard average instead of peaks and distributions.
- Setting every request equal to an oversized limit and then wondering why Pods do not schedule.
- Increasing a memory limit without investigating an unbounded cache or leak.
Resource pressure can surface as failed health checks, so pair this guide with Kubernetes probe design. During a deploy, requests also determine whether the cluster has room for the extra Pod allowed by maxSurge in a rolling update.
Frequently asked questions
Can a container use more than its CPU request?
Yes, when node capacity and any CPU limit allow it. The request influences scheduling and CPU weighting under contention; it is not normally a ceiling.
Does exceeding a CPU limit kill the Pod?
Not merely for CPU use. CPU time is constrained, which can increase latency. Memory-limit enforcement can instead involve OOM termination.
Why is a Pod Pending when node usage looks low?
The scheduler evaluates requests against allocatable capacity, not only current usage. Other Pods may have reserved scheduling capacity that they are not using at that instant.
What is the primary reference?
Kubernetes documents the current semantics, units, scheduling, and cgroup behavior in Resource Management for Pods and Containers.
Test resource and failure reasoning
The linked assessment covers scheduler requests, CPU ceilings, OOM behavior, probes, Compose, and rollout budgets.
A practical assessment covering Docker Compose health checks, container DNS and storage, Kubernetes probes, resources, OOM diagnostics, and safer rolling updates. Start the trivia-style player right inside the article.Docker and Kubernetes Production Readiness Mock Test
Practical takeaway: requests describe the capacity the scheduler should plan for; limits constrain runtime. Tune both from evidence and diagnose CPU, OOM, and eviction as separate failure modes.
Discussion
0 comments
Ask a question or share what stood out to you.