Kubernetes Requests vs Limits: What's the Difference?

Kubernetes Requests vs Limits: What's the Difference?

In Kubernetes, a resource request is the amount of CPU or memory the scheduler reserves for a container when placing its pod on a node, and a resource limit is the maximum the container is allowed to use at runtime. Requests decide where a pod runs and how CPU is shared under contention. Limits decide what happens when a container tries to use more: CPU gets throttled, and memory gets the container killed.

What Is a Resource Request?

A request tells the kube scheduler how much CPU and memory a container needs. The scheduler only places a pod on a node whose unreserved allocatable capacity covers the sum of the pod's requests. If no node has room, the pod stays Pending.

Requests are not caps. A container that requests 250m CPU can use more when the node has spare capacity. Under CPU contention, requests also act as weights: containers get CPU time roughly in proportion to what they requested.

What Is a Resource Limit?

A limit is the most CPU or memory a container may use. According to the Kubernetes resource management documentation, the kubelet and container runtime apply limits, and on Linux the kernel enforces them with cgroups. Limits do not affect scheduling at all.

Requests vs Limits at a Glance

How CPU and Memory Limits Fail Differently

CPU Limits: Throttling

CPU is compressible, so exceeding a CPU limit slows the container instead of killing it. The kernel's Completely Fair Scheduler (CFS) gives each container a quota per scheduling period, 100 ms by default. A container with a 500m limit gets 50 ms of CPU time per 100 ms period. Once it spends that budget, all its threads pause until the next period, even if the node is otherwise idle.

This is why throttling hides on dashboards. A multithreaded service with 4 busy threads can burn a 50 ms budget in about 12.5 ms of wall time, then sit paused for the remaining 87.5 ms. Average CPU usage looks moderate while p99 latency climbs.

Memory Limits: OOMKills

Memory is not compressible. When a container's memory use exceeds its limit, the kernel's out of memory (OOM) killer terminates the process. Kubernetes records the reason as OOMKilled, the exit code is 137 (128 plus signal 9, SIGKILL), and the container restarts according to the pod's restart policy. Repeated OOMKills show up as CrashLoopBackOff.

How Requests and Limits Set QoS Classes

Kubernetes assigns every pod a Quality of Service (QoS) class based on its requests and limits:

One rule surprises people: if you set a limit without a request, Kubernetes copies the limit into the request. A container with only limits set can end up Guaranteed and harder to schedule than you intended.

How to Detect Resource Problems

These PromQL queries use cAdvisor metrics (exposed by the kubelet) and kube state metrics, which most Prometheus compatible setups already collect.

CPU throttling ratio (share of scheduling periods where the container was throttled):

sum by (namespace, pod, container) (
  rate(container_cpu_cfs_throttled_periods_total{container!=""}[5m])
)
/
sum by (namespace, pod, container) (
  rate(container_cpu_cfs_periods_total{container!=""}[5m])
)

Values above 0.25 for 15 minutes on a latency sensitive service deserve investigation. Throttling on a batch job may be acceptable.

Memory working set as a share of the limit (the kernel uses working set, not total usage, when deciding OOM):

sum by (namespace, pod, container) (
  container_memory_working_set_bytes{container!=""}
)
/
sum by (namespace, pod, container) (
  kube_pod_container_resource_limits{resource="memory"}
)

Alert above 0.9 so you can act before the OOMKill.

Recent OOMKills:

kube_pod_container_status_last_terminated_reason{reason="OOMKilled"} == 1

CPU usage as a share of requests (finds overprovisioning):

sum by (namespace, pod, container) (
  rate(container_cpu_usage_seconds_total{container!=""}[5m])
)
/
sum by (namespace, pod, container) (
  kube_pod_container_resource_requests{resource="cpu"}
)

Containers that sit below 0.3 for weeks are reserving capacity they never use, which is often the largest source of Kubernetes cost waste.

Symptom to Cause: Troubleshooting Table

Should You Set CPU Limits?

This is the most debated setting in Kubernetes resource management, and the right answer depends on the workload:

• Arguments against CPU limits: throttling adds tail latency even when the node has idle CPU. CPU requests already guarantee each container its share under contention, so a well requested container is protected without a limit.
• Arguments for CPU limits: multitenant clusters need a hard ceiling so one team cannot consume a node. Limits also make performance more predictable, which helps capacity planning and load tests reflect production.

How to Set Requests and Limits by Workload Type

Base values on at least one to two weeks of production usage that includes peak traffic, and revisit them after major releases. The Vertical Pod Autoscaler in recommendation mode can suggest values from history. In place pod resize, which lets you change CPU and memory on running pods without recreating them, is stable as of Kubernetes v1.35, which makes adjustments less disruptive.

Runtime Gotchas That Cause Throttling and OOMKills

Go. Before Go 1.25, the runtime set GOMAXPROCS to the node's CPU count, so a service limited to 2 CPUs on a 64 core node could run 64 threads against a 2 CPU quota and throttle hard. Go 1.25 made GOMAXPROCS container aware on Linux, defaulting to the cgroup CPU limit. Older Go versions need GOMAXPROCS set explicitly or a library such as automaxprocs. For memory, set GOMEMLIMIT a little below the container limit so the garbage collector works harder before the kernel kills the process.

JVM. Modern JVMs read container limits, and by default the maximum heap is 25% of container memory. Teams often raise -XX:MaxRAMPercentage to 75% or more and then hit OOMKills because metaspace, thread stacks, code cache, and direct buffers also count toward the limit. Leave headroom for non heap memory.

Node.js. V8's heap size may not match your container limit on older Node versions. Set --max-old-space-size below the memory limit.

Example: A Balanced Configuration

apiVersion: apps/v1
kind: Deployment
metadata:
  name: checkout-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: checkout-api
  template:
    metadata:
      labels:
        app: checkout-api
    spec:
      containers:
        - name: checkout-api
          image: registry.example.com/checkout-api:4.2.0
          resources:
            requests:
              cpu: "500m"        # p95 of observed usage over 14 days
              memory: "768Mi"    # p99 working set plus ~20% headroom
            limits:
              memory: "768Mi"    # equal to request: predictable scheduling, no overcommit
              # No CPU limit: latency sensitive service, avoid CFS throttling
          env:
            - name: GOMEMLIMIT
              value: "690MiB"    # ~90% of the memory limit, gives the GC room to react

Monitoring Requests and Limits in Production

Right sizing is ongoing because usage changes with every release. Middleware's Kubernetes monitoring shows throttling, memory against limits, and OOMKill events alongside the traces and logs from the same pods, so you can tell whether a latency spike came from code or from resource settings.