Resource Requests and Limits

Every container can specify CPU and memory requests (guaranteed minimum) and limits (maximum allowed). These values determine scheduling decisions, quality of service, and what happens when resources are exhausted.

Setting Requests and Limits

apiVersion: v1
kind: Pod
metadata:
  name: resource-demo
spec:
  containers:
    - name: app
      image: nginx
      resources:
        requests:
          cpu: "250m"
          memory: "128Mi"
        limits:
          cpu: "500m"
          memory: "256Mi"

• CPU is measured in millicores. 250m equals 0.25 of a CPU core.
• Memory is measured in bytes. Common units are Mi (mebibytes) and Gi (gibibytes).

Requests vs Limits

Requests tell the scheduler how much resource a container needs. The pod is only placed on a node with enough available capacity.

Limits cap the maximum a container can use. If a container exceeds its memory limit, it is OOMKilled (Out of Memory Killed). CPU is throttled when it exceeds the limit but the container is not killed.

QoS Classes

Kubernetes assigns a Quality of Service class based on requests and limits:

• Guaranteed -- requests equal limits for all containers
• Burstable -- at least one container has requests set but limits differ
• BestEffort -- no requests or limits set

kubectl get pod resource-demo -o jsonpath='{.status.qosClass}'

Under memory pressure, Kubernetes evicts BestEffort pods first, then Burstable, and Guaranteed pods last.

Checking Resource Usage

kubectl describe node <node-name> | grep -A 5 "Allocated resources"
kubectl top pods