Kubernetes resource requests and limits determine where pods can run, how much capacity the scheduler reserves, and what happens when a workload is busy or a node is under pressure. This guide provides a repeatable way to size CPU and memory, understand Kubernetes QoS classes, diagnose OOMKilled containers, and tune Deployments from observed metrics without treating a single utilization snapshot as a permanent answer.
Overview
A resource request is the amount of CPU or memory Kubernetes uses when scheduling a pod. The scheduler uses requests to decide whether a node has enough allocatable capacity. A resource limit is a ceiling enforced while the container runs. Requests affect placement; limits affect runtime behavior.
CPU is measured in cores or millicores: 500m represents half a CPU core. Memory is normally expressed in bytes using quantities such as 256Mi or 1Gi. CPU can be throttled when a container reaches its limit. Memory is not reclaimed in the same way: a container that exceeds its memory limit can be terminated, commonly producing an OOMKilled reason.
Requests and limits should answer different questions:
- Request: How much capacity does this workload need for reliable scheduling and normal operation?
- Limit: How much additional resource may it consume before Kubernetes or the runtime constrains it?
Resource settings also influence a pod's Quality of Service (QoS) class. A pod is typically classified as Guaranteed when every container has CPU and memory requests equal to its corresponding limits. It is BestEffort when no container has requests or limits. Pods that fall between those definitions are Burstable. QoS affects how Kubernetes evaluates pods during resource pressure, but it does not replace sensible sizing or application-level resilience.
Requests-and-limits decision table
| Workload pattern | Starting approach | What to watch |
|---|---|---|
| Steady API service | Request near normal sustained use; set a limit above expected use if bursting is useful | Latency, CPU throttling, memory working set, restart count |
| Memory-sensitive worker | Request above normal working set; set a limit with room for known batch variation | OOMKilled events, garbage collection, queue depth, peak memory |
| Short-lived batch job | Request based on the resources needed to finish within the target window | Runtime, retries, peak memory, node fragmentation |
| Sidecar-heavy pod | Size each container separately, including proxies and agents | Per-container usage rather than only pod totals |
How to estimate
Start with measurements from representative traffic or jobs. For each container, collect CPU usage and memory usage over a period that includes ordinary operation, deployments, scheduled work, and known traffic peaks. A short test during a quiet period is useful for a first draft, but it is weak evidence for production sizing.
Use this simple worksheet for each container:
- Record typical CPU and memory usage.
- Record a high-but-plausible value, not an unexplained one-off spike.
- Choose the CPU request near the sustained level required for acceptable latency.
- Choose the memory request above the normal working set, including application overhead.
- Set limits only where a ceiling provides operational value, and leave room for legitimate bursts.
- Validate the result against node allocatable capacity and replica count.
For a first estimate, a useful capacity check is:
total requested CPU = replicas × (application request + sidecar requests)
Apply the same calculation to memory. Compare the totals with allocatable node capacity, not the raw hardware total. Kubernetes system components, daemon sets, and provider reservations consume part of a node's capacity. Also account for rolling updates: a Deployment may temporarily need capacity for old and new replicas at the same time.
Do not calculate a limit by multiplying a request by an arbitrary constant and assume the result is safe. The right margin depends on traffic shape, garbage collection, caches, concurrency, batch size, and failure behavior. A limit that is too low can cause throttling or OOMKilled containers; a request that is too high can leave schedulable capacity unused and increase infrastructure cost.
Inputs and assumptions
Keep a sizing worksheet with these inputs:
- Replica count: Include the minimum operating count and the maximum expected count from autoscaling.
- Container inventory: List the application, proxy, telemetry agent, and any other container in the pod.
- CPU profile: Note sustained usage, short bursts, throttling, and latency during load.
- Memory profile: Note working set, peak usage, cache behavior, leaks, and termination history.
- Availability assumptions: Include rollout surge, node failure recovery, and disruption budgets where relevant.
- Autoscaling inputs: If an HPA uses resource utilization as a target, remember that utilization is commonly evaluated relative to the relevant resource request. A request that is far too low or high can therefore distort scaling behavior.
A manifest should make the decision visible and reviewable:
resources:
requests:
cpu: "250m"
memory: "256Mi"
limits:
cpu: "1"
memory: "512Mi"These values are examples, not universal recommendations. Use namespace-level policies such as a LimitRange carefully: defaults can prevent unbounded pods, but an unnoticed default may also create misleading scheduling or autoscaling behavior. Check the effective pod specification after admission, not only the source manifest.
Worked examples
Example 1: A replicated API
Suppose an API has six replicas. Each pod contains an application container requesting 250m CPU and 256Mi memory, plus a telemetry sidecar requesting 50m CPU and 64Mi memory. The pod request is therefore 300m CPU and 320Mi memory. Six replicas require 1,800m CPU and 1,920Mi memory before accounting for rollout surge, other workloads, or node-reserved capacity.
If the API's memory usage rises above its limit during realistic load, increasing only the request will not prevent termination. Investigate the peak, heap configuration, cache size, and concurrency, then raise the limit or correct the application behavior. If CPU latency worsens while usage approaches the limit, check throttling and test whether a higher limit improves results without making node capacity unpredictable.
Example 2: A worker with uneven jobs
A queue worker may use little CPU while waiting and much more while processing a job. Its CPU request should represent the capacity needed for the desired throughput, not merely its idle average. Memory should reflect the largest supported job plus application overhead. If job sizes vary significantly, a fixed memory limit may either waste capacity or cause OOMKilled failures; splitting workloads by job class or bounding per-job concurrency may be safer than endlessly increasing the limit.
In both examples, compare pod-level observations with per-container metrics. A sidecar can be the source of memory pressure even when the application looks correctly sized.
When to recalculate
Revisit resource settings after a major code release, dependency change, traffic-pattern shift, replica-count change, or new sidecar. Recalculate during capacity planning, after node-size changes, and when a Deployment begins to scale differently than expected. Also review them after OOMKilled events, CPU throttling alerts, pod evictions, slow rollouts, or unexplained pending pods.
A practical tuning loop is:
- Inspect actual usage and events with your metrics and logging tools.
- Separate normal peaks from faults, leaks, and load-test artifacts.
- Change one resource dimension or workload behavior at a time.
- Deploy gradually and compare latency, throughput, restarts, throttling, and cost signals.
- Recheck scheduling with the maximum replica count and rollout surge.
- Record the evidence and the next review trigger in the workload documentation.
Resource management is a living capacity decision, not a value set once in a template. Treat requests as a scheduling contract, limits as an operational boundary, and metrics as the evidence for changing either. For related operational work, pair this review with a Kubernetes deployment checklist and the guidance on choosing an observability stack.
