Kubernetes Resource Requests and Limits: A Practical Sizing and Tuning Guide

Overview

A container's resource request is the amount Kubernetes uses when scheduling a Pod. It helps the scheduler decide whether a node has enough allocatable capacity. A resource limit is the maximum amount a container is intended to consume for a resource. Requests and limits are configured separately for CPU and memory.

For example:

resources:
  requests:
    cpu: "250m"
    memory: "512Mi"
  limits:
    cpu: "1"
    memory: "1Gi"

This configuration asks Kubernetes to reserve 250 millicores and 512 MiB for scheduling purposes, while allowing the container to use up to one CPU and 1 GiB when capacity is available. The values are not interchangeable: setting a high limit does not make that capacity available for scheduling if the request remains low, and setting a high request can leave nodes underutilized if the workload rarely uses it.

CPU and memory also behave differently. CPU is a compressible resource: under contention, a container can generally receive less CPU time or be throttled. Memory is not compressible in the same way. When a node runs short of memory, Kubernetes may evict Pods, and a container that exceeds its memory limit may be terminated by the runtime or kernel. This is why Kubernetes CPU and memory sizing should be based on separate observations rather than one shared rule.

What to track

Requests, limits, and actual usage

For every production workload, keep a small record of the configured request and limit alongside observed usage. Track at least:

• CPU request and limit for each container.
• Memory request and limit for each container.
• Typical usage, such as a median or representative daytime level.
• High-water usage during deployments, batch jobs, traffic peaks, and maintenance tasks.
• CPU throttling indicators, if your monitoring system exposes them.
• Container restarts, OOM kills, Pod evictions, and Pending status.
• Node allocatable capacity, saturation, and headroom.
• Autoscaler behavior, including frequent scaling or inability to add capacity.

A single average is not enough. A service may have modest normal usage but require significantly more memory during a cache warm-up or deployment. Record the period represented by each measurement and retain enough history to compare ordinary operation with known peaks.

Useful inspection commands

Start with the workload's declared configuration:

kubectl get deployment <deployment> -n <namespace> -o yaml
kubectl describe pod <pod> -n <namespace>

To view node capacity, allocatable resources, and current Pod placement:

kubectl describe node <node>
kubectl get pods -A -o wide

If the metrics API is installed, compare current usage with declarations:

kubectl top pods -A --containers
kubectl top nodes

These commands provide a snapshot, not a sizing decision. Use your monitoring or observability tools for historical percentiles, daily patterns, and correlation with traffic or job schedules. For a broader diagnostic workflow, see the Kubernetes troubleshooting decision tree.

Reference table for common workload patterns

Understand Kubernetes QoS classes

Kubernetes assigns a QoS class to each Pod from its container resource configuration:

• Guaranteed: each container has CPU and memory requests, and the request equals the limit for both resources.
• Burstable: the Pod has at least one request or limit, but does not meet the Guaranteed conditions.
• BestEffort: no container in the Pod has CPU or memory requests or limits.

QoS class is one input into eviction decisions during node pressure; it is not a substitute for correct sizing. A Guaranteed Pod can still fail if it reaches a memory limit, and a Burstable Pod can be perfectly appropriate when its burst behavior is understood. Check the resulting class after changing a workload rather than assuming the YAML change had the intended effect.

Cadence and checkpoints

Resource management works best as a recurring operating practice rather than a one-time manifest edit. Use a monthly review for active production services and a quarterly review for stable workloads, adjusting the interval when traffic or architecture changes quickly.

Monthly checkpoint

1. Compare current requests and limits with recent CPU and memory percentiles.
2. Review throttling, OOM kills, restarts, evictions, and Pending Pods.
3. Check node headroom and whether workloads are concentrated on a small set of nodes.
4. Look for autoscaling changes, recurring scale-ups, or replicas that cannot be scheduled.
5. Record one decision for each outlier: retain, increase, decrease, or investigate.

Quarterly capacity review

At least quarterly, compare resource assumptions with product traffic, release volume, data growth, and infrastructure changes. Review whether a new Kubernetes deployment strategy, sidecar, service mesh component, or observability agent has changed the Pod's footprint. Recheck requests after major version upgrades because application runtimes and dependencies can alter startup or steady-state behavior.

A simple sizing worksheet can use these columns:

How to interpret changes

If a Pod is frequently throttled, first determine whether the CPU limit is too restrictive or whether the application genuinely lacks CPU. Raising a limit may reduce throttling but can also increase node contention if many workloads burst simultaneously. Check latency, queue depth, and node-level CPU pressure before changing it.

If memory usage approaches the limit, do not respond by increasing the limit blindly. Confirm whether the growth is expected, caused by caching, or indicative of a leak. A higher limit can postpone failure while allowing the workload to consume more node memory. Compare the change with node capacity and the impact on neighboring Pods.

Frequent Pod evictions usually require node-pressure investigation as well as workload review. Examine memory and disk pressure, actual node allocatable capacity, and which Pods are being removed. A request that is too low can make scheduling appear efficient while leaving the node vulnerable to contention; a request that is too high can create unnecessary Pending Pods and wasted capacity.

When a Pod remains Pending, inspect scheduler events and compare its requests with allocatable capacity, affinity rules, taints, and available nodes. Resource requests may be the immediate constraint, but they are not always the only one. For autoscaling, remember that CPU-based utilization commonly relates usage to the configured request; changing the request can therefore change scaling behavior even when application traffic is unchanged.

When to revisit

Revisit Kubernetes resource requests and limits on the monthly or quarterly cadence above, and immediately after any event that changes workload behavior. Useful triggers include a sustained traffic increase, a new release with a different runtime profile, a dependency or sidecar addition, a change in replica or autoscaling settings, a node-pool migration, or repeated throttling, OOM kills, evictions, and scheduling failures.

Before applying a change, capture the current values and the evidence behind it. Make one controlled adjustment where possible, observe the result through a representative workload period, and update the worksheet. If the change affects production reliability or incident risk, connect it to the team's incident response process and document the rollback condition. The Kubernetes cost optimization checklist can help connect sizing decisions with capacity and spend reviews.

For a practical next step, select the five workloads with the highest memory usage or most frequent scheduling alerts. Export their requests, limits, QoS classes, recent usage, and reliability events. Classify each value as evidence-based, provisional, or unknown; then replace the unknowns with a monitoring window and an owner. Repeat the review after the next meaningful workload change. This turns resource management from static YAML maintenance into a measurable Kubernetes operations habit.