Resource requests and limits are capacity signals, scheduling inputs and safety boundaries. Setting them well improves reliability and cost efficiency; copying arbitrary values into every Deployment creates Pending Pods, CPU throttling, OOM kills and wasted nodes.

The right values come from observed behavior and service objectives. This guide explains how Kubernetes interprets CPU and memory, how requests affect scheduling and autoscaling, how limits behave at runtime, and how to build a tuning loop as traffic changes.

What you will learn

  • The scheduler places Pods using requests, not current utilization.
  • CPU limits can throttle; memory limits can cause an out-of-memory termination.
  • HPA utilization targets depend on requests, so inaccurate requests distort scaling.
  • Use measurements, percentiles and load tests instead of one universal ratio.

Requests are promises to the scheduler

A request describes the CPU or memory a container needs for placement. The scheduler compares Pod requests with node allocatable capacity and existing reservations. A node can appear idle yet reject a Pod when requested capacity is committed.

CPU is expressed in cores or millicpu: 500m means half a CPU. Memory commonly uses binary units such as Mi and Gi. Be precise: 400m memory is not 400 MiB.

Limits are runtime boundaries

A CPU limit is enforced by throttling CPU time. The process continues, but tail latency can rise. A memory limit behaves differently: exceeding it can produce an OOM kill and a restart.

Limits protect neighbors and node stability, but a tight limit becomes an availability problem. Measure cache growth, garbage collection, startup peaks and temporary buffers.

A complete resource specification

Set resources for every application container and sidecar. Ignoring a proxy or logging sidecar distorts capacity planning. The values below show structure, not universal sizing.

Measure under representative load before promotion, then verify actual production behavior after deployment.

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

QoS and eviction pressure

Kubernetes assigns Guaranteed, Burstable or BestEffort QoS based on resource configuration. QoS influences eviction under node pressure but does not replace correct sizing.

A Guaranteed Pod with an undersized memory limit can still hit its own boundary. Priority, actual usage relative to requests and node conditions also influence pressure behavior.

Choose values from evidence

Use load tests and production-like telemetry. For memory, examine steady working set plus peaks and leave a justified margin. For CPU, relate utilization to throughput and latency. Requests should cover the capacity needed to meet the service objective.

Review percentiles per version and replica, not only cluster averages. Revisit values after runtime upgrades, features, sidecar changes and traffic shifts.

Diagnose common failures

For Pending Pods, read scheduling events and compare requests with node allocatable capacity, quotas, affinity and taints. For restarts, inspect previous container state and logs.

Correlate CPU throttling with latency. High utilization is not automatically bad if latency is healthy and autoscaling has room. The goal is predictable performance with efficient capacity.

kubectl describe pod <pod> -n <namespace>
kubectl top pod <pod> -n <namespace> --containers
kubectl get pod <pod> -n <namespace> -o yaml

Production checklist

  • Define CPU and memory requests for every container.
  • Base values on representative load tests and percentiles.
  • Alert on OOM kills, restarts, throttling and unschedulable Pods.
  • Use LimitRange and ResourceQuota as namespace guardrails.
  • Revisit values after releases and traffic changes.
  • Coordinate requests with HPA targets and node capacity.

Frequently asked questions

Should CPU request and limit be equal?

Not always. Equal values provide isolation but can throttle bursty services. Choose from latency needs, multi-tenancy risk and measurements.

Why is a Pod Pending when node CPU looks low?

Scheduling uses requested capacity and placement constraints, not only live utilization.

Do memory limits prevent every node OOM?

No. Node daemons, unbounded workloads, memory-backed volumes and overall capacity still require monitoring and reservation.

Continue learning Kubernetes

Official Kubernetes references