How to set Kubernetes resource requests and limits correctly

Setting resource requests and limits

Each container can declare resource requests and limits. Requests are what the scheduler reserves and uses to place pods; limits cap how much a container may consume. Getting these right prevents noisy-neighbor problems, out-of-memory kills, and wasted capacity.

Prerequisites

• Workloads running in the cluster.
• A way to observe usage, such as metrics-server or Prometheus.

Steps

1. Understand requests vs limits

The scheduler places a pod only on a node with enough free CPU and memory to satisfy its requests. Limits are enforced at runtime: CPU over the limit is throttled, memory over the limit triggers an OOM kill.

2. Measure current usage

kubectl top pods

For history and percentiles, query Prometheus for container CPU and memory over a representative period.

3. Set initial requests and limits

resources:
  requests:
    cpu: 250m
    memory: 256Mi
  limits:
    cpu: 500m
    memory: 512Mi

Set memory request near typical usage and the limit with headroom; avoid setting CPU limits too tight as throttling hurts latency.

4. Understand QoS classes

Kubernetes assigns Guaranteed (requests equal limits), Burstable (requests below limits), or BestEffort (none set). Under memory pressure, BestEffort and Burstable pods are evicted first. Critical workloads should be Guaranteed.

5. Add LimitRange defaults

Apply sensible defaults per namespace so pods without explicit values still get them:

apiVersion: v1
kind: LimitRange
metadata:
  name: defaults
spec:
  limits:
    - default:
        cpu: 500m
        memory: 512Mi
      defaultRequest:
        cpu: 250m
        memory: 256Mi
      type: Container

6. Right-size over time

Review p95 usage periodically and adjust. The Vertical Pod Autoscaler can recommend values automatically.

Verification

Apply the resources and confirm the QoS class with kubectl get pod <pod> -o jsonpath='{.status.qosClass}'. Confirm pods schedule successfully and that memory usage stays under the limit so no OOM kills appear in kubectl describe pod.

Next Steps

Adopt the Vertical Pod Autoscaler for ongoing recommendations, set ResourceQuotas per namespace to cap total consumption, and combine right-sizing with the HPA and Cluster Autoscaler for cost-efficient elasticity.