Requests and Limits

A cluster is shared. If one pod eats all the memory of a node, every neighbour suffers. Kubernetes needs to know how much each app needs, and how much it may take. You tell it with requests and limits. In this lesson, you will learn both, and see what happens when a limit is broken.

• Nodes are shared by many pods
• Requests say what you need
• Limits say what you may take

Requests versus limits

These two words are easy to mix up. A request is what your container needs, to run well. The scheduler uses requests, to find a node with enough room. A limit is the most your container may use. The kubelet enforces limits at run time. Think of a restaurant. The request is the table you reserve. The limit is the most food you may order. Resources come in two main kinds, C P U, measured in cores, or in millicores, and memory, measured in mebibytes and gibibytes.

Requests and limits in YAML

Here is how they look in a pod file. Under resources, we have requests, and limits. This container requests fifty mebibytes of memory, and one hundred millicores of C P U. A millicore is a thousandth of a core, so this is one tenth of a core. It may use at most one hundred mebibytes of memory, and two hundred millicores. A container that exceeds its C P U limit is slowed down. A container that exceeds its memory limit is killed.

apiVersion: v1
kind: Pod
metadata:
  name: hungry
spec:
  containers:
  - name: stress
    image: polinux/stress
    command: ["stress"]
    args: ["--vm", "1", "--vm-bytes", "200M", "--vm-hang", "1"]
    resources:
      requests:
        memory: 50Mi
        cpu: 100m
      limits:
        memory: 100Mi
        cpu: 200m

Breaking a limit

Let's see both failures. First, a program that tries to allocate two hundred megabytes, with a hundred megabyte limit. The kubelet stops it, and the status says, O O M killed, out of memory. It tries again and again, the restarts column climbs. Second, a pod that requests one hundred cores, and five hundred gibibytes of memory. No node can fit it, so it stays pending. The events explain why, insufficient C P U, and insufficient memory.

kubectl apply -f oom.yaml
pod/hungry created
kubectl get pod hungry
NAME     READY   STATUS      RESTARTS      AGE
hungry   0/1     OOMKilled   2 (19s ago)   25s
kubectl describe pod hungry | grep -E 'Reason|Exit Code' | head -2
      Reason:       OOMKilled
      Exit Code:    1
kubectl apply -f big.yaml
pod/greedy created
kubectl get pod greedy
NAME     READY   STATUS    RESTARTS   AGE
greedy   0/1     Pending   0          5s
kubectl describe pod greedy | tail -1 | cut -c1-110
  Warning  FailedScheduling  5s    default-scheduler  0/3 nodes are available: 3 Insufficient cpu, 3 Insuffici

apiVersion: v1
kind: Pod
metadata:
  name: hungry
spec:
  containers:
  - name: stress
    image: polinux/stress
    command: ["stress"]
    args: ["--vm", "1", "--vm-bytes", "200M", "--vm-hang", "1"]
    resources:
      requests:
        memory: 50Mi
        cpu: 100m
      limits:
        memory: 100Mi
        cpu: 200m

apiVersion: v1
kind: Pod
metadata:
  name: greedy
spec:
  containers:
  - name: app
    image: nginx:1.27
    resources:
      requests:
        cpu: "100"
        memory: 500Gi

Summary