Some of the most common Kubernetes problems trace back to a few lines of configuration: resource requests and limits. Set them too low and pods get throttled, evicted or killed. Set them too high and you pay for capacity that sits idle. Skip them entirely and one noisy application can starve everything else on a node.
This guide explains what requests and limits are, how Kubernetes uses them for CPU and memory, how they decide a pod's Quality of Service class, and practical ways to choose the right values.
What Are Requests and Limits?
Every container in a pod can declare two values for each resource, most commonly CPU and memory:
- Request: the amount of the resource the container is guaranteed. The scheduler uses requests to decide which node a pod can run on.
- Limit: the maximum amount the container is allowed to use. The kubelet and Linux kernel enforce limits at runtime.
A simple way to think about it: the request is what you reserve, the limit is the ceiling you cannot go above.
Resource Units
CPU is measured in cores. One CPU equals one physical or virtual core. You can request fractions using millicores, where 1000m equals one core, so 250m is a quarter of a core.
Memory is measured in bytes, usually written with binary suffixes such as Mi (mebibytes) and Gi (gibibytes). Be careful with the difference between "M" and "Mi"; they are close but not identical, and mixing them causes confusion.
How Requests Affect Scheduling
When you create a pod, the scheduler adds up the requests of all its containers and looks for a node with enough unreserved capacity. It does not look at actual usage. A node with 4 CPUs that already has 3.5 CPUs requested can only accept pods requesting 500m or less, even if the existing pods are mostly idle.
This has two consequences. Requests that are too high waste capacity and push up costs, because nodes fill up with reservations nobody uses. Requests that are too low let the scheduler pack too many pods onto a node, leading to contention at busy times.
If no node has enough room, the pod stays in the Pending state. Our guide to debugging crashing pods in Kubernetes covers how to diagnose Pending and other failure states.
How CPU Limits Work: Throttling
CPU is a compressible resource. When a container hits its CPU limit, it is not killed. Instead, the kernel throttles it, giving it less CPU time within each scheduling period. The application keeps running, just more slowly.
Throttling can be surprising. A container may show low average CPU usage yet still be throttled during short bursts, causing latency spikes. For this reason, many teams set CPU requests on every container but use CPU limits carefully, or leave them off for latency-sensitive services, as long as requests are accurate and namespaces have quotas. Whichever policy you choose, monitor throttling metrics so you can see its effect.
How Memory Limits Work: OOMKilled
Memory is not compressible. If a container tries to use more memory than its limit, the kernel's out-of-memory killer terminates it, and Kubernetes reports the reason as OOMKilled. The pod then restarts according to its restart policy, which can lead to CrashLoopBackOff if it keeps happening.
Nodes can also run short of memory overall. When that happens, the kubelet evicts pods to protect the node, starting with those using the most memory above their requests and with lower priority. This is why memory requests should reflect real usage, and why a memory limit is generally recommended.
Quality of Service (QoS) Classes
Kubernetes assigns each pod a QoS class based on its requests and limits. The class influences which pods are evicted first under node pressure.
Guaranteed
Every container has CPU and memory requests and limits set, and the requests equal the limits. These pods are the last to be evicted. Use this for critical workloads such as databases.
Burstable
At least one container has a request or limit set, but the pod does not meet the Guaranteed criteria. Most applications fall into this class. They can use extra resources when available.
BestEffort
No container has any requests or limits. These pods can use whatever is free but are the first to be evicted. Avoid this class for anything important.
Setting Defaults with LimitRange and ResourceQuota
Relying on every developer to remember requests and limits does not scale. Kubernetes provides two namespace-level controls:
- LimitRange sets default requests and limits for containers that do not specify them, and can enforce minimum and maximum values per container.
- ResourceQuota caps the total CPU, memory, storage and object counts that a whole namespace can consume. It is ideal for multi-team clusters.
Policy engines can go further, for example rejecting any deployment without memory limits. See how to enforce policies in Kubernetes with OPA.
How to Choose the Right Values
- Measure real usage. Observe CPU and memory over at least a week of normal traffic, including peaks, using Prometheus and Grafana dashboards or your cloud monitoring tool.
- Set memory requests near typical peak usage and memory limits with sensible headroom above that, based on how the application behaves under load.
- Set CPU requests near typical usage so the scheduler places pods realistically, and decide on a clear team policy for CPU limits.
- Account for the runtime. Languages with their own memory managers, such as Java and Node.js, should be configured to respect the container limit, otherwise they may try to use more memory than allowed.
- Load test. Confirm behaviour under realistic peak traffic before going to production.
- Review regularly. Usage changes as the application evolves.
Requests, Limits and Autoscaling
The Horizontal Pod Autoscaler (HPA) usually scales based on utilisation as a percentage of the request. If requests are wrong, scaling decisions are wrong too. The Vertical Pod Autoscaler (VPA) can recommend or automatically adjust requests based on observed usage, which makes it a useful right-sizing tool even in recommendation-only mode. Learn more in how to autoscale apps in Kubernetes with HPA and VPA.
Newer Kubernetes versions also support in-place pod resize, which lets you change a running container's CPU and memory without recreating the pod. It is worth checking whether your cluster version and tooling support it.
Requests, Limits and Cloud Costs
Because node capacity is allocated by requests, oversized requests are one of the biggest sources of wasted Kubernetes spend. Tools such as Kubecost, OpenCost, Goldilocks and the VPA recommender highlight the gap between requested and used resources. Combine them with the practices in FinOps for DevOps teams and cloud cost management.
Common Mistakes
- Running production workloads with no requests or limits (BestEffort).
- Copying the same values to every service regardless of actual needs.
- Setting memory limits below the application's normal peak, causing repeated OOMKills.
- Setting very low CPU limits on latency-sensitive services, causing throttling.
- Ignoring init containers and sidecars, which also consume resources.
- Never revisiting values after the initial deployment.
Conclusion
Requests tell Kubernetes what your containers need; limits tell it where to stop them. Together they decide scheduling, runtime behaviour, eviction order and a large part of your cloud bill. Base your values on measured usage, enforce sensible defaults with LimitRanges and quotas, monitor throttling and OOMKills, and review regularly with tools like the VPA. For more hands-on Kubernetes learning, start with our Kubernetes tutorial for beginners.
