How to Set Kubernetes Requests and Limits

Requests vs limits - what each field does

Every container in a pod can declare two resource fields:

• requests - the guaranteed minimum. The scheduler only places the pod on a node that has this much free. It also determines the pod's QoS class, which controls eviction order under memory pressure.
• limits - the hard ceiling. A CPU-throttled container keeps running but gets less CPU time. A container that exceeds its memory limit is OOM-killed immediately.

Without requests, the scheduler assumes the pod needs nothing and can over-pack the node. Without limits, one runaway pod can consume every byte of RAM on the host.

Adding resources to a Deployment

Place the resources block inside the container spec, under containers[*]:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: worker
spec:
  replicas: 1
  selector:
    matchLabels:
      app: worker
  template:
    metadata:
      labels:
        app: worker
    spec:
      containers:
      - name: worker
        image: busybox:1.36
        command: ["sleep", "86400"]
        resources:
          requests:
            cpu: 50m
            memory: 64Mi
          limits:
            cpu: 200m
            memory: 128Mi

Apply it and confirm the values landed:

kubectl apply -f deployment.yaml
kubectl get deployment worker -o yaml | grep -A6 resources

Choosing good values

• CPU requests are in millicores (m). 100m = 0.1 vCPU. Start low (50-100m for a light worker) and raise once you have real usage data from kubectl top pods.
• Memory requests should match steady-state RSS, not peak. Check with kubectl top pods or your metrics stack.
• CPU limits - setting a CPU limit throttles burst performance. Many teams set limits.cpu to 2-4x requests.cpu or omit it entirely and rely on requests for scheduling fairness.
• Memory limits should be set - OOM kills are disruptive but recoverable; a node running out of memory entirely is not. Set limits.memory to peak usage plus a safety margin (1.5-2x is common).

QoS classes

Kubernetes assigns a QoS class based on your resource config, which determines eviction priority under node pressure:

Running with no resources at all means BestEffort - the pod is the first to go when the node runs low on memory.