Evicted: The kubelet removed the pod because the node ran short of a resource

Evicted means the node came under resource pressure — memory, disk, or inodes — and the kubelet removed pods to protect the node. Which pods go first depends on their QoS class and how far they exceeded their requests.

Applies to: All Kubernetes versions

What it means

Eviction is a node-level protection mechanism, distinct from an OOM kill. When a node crosses an eviction threshold for memory, ephemeral storage, inodes, or PIDs, the kubelet selects pods to remove rather than letting the node become unstable. Selection is not arbitrary: BestEffort pods go first, then Burstable pods that are using more than they requested, and Guaranteed pods last. The evicted pod's object remains in the cluster with status Failed and reason Evicted, which is why evicted pods accumulate visibly in kubectl get pods long after the incident.

Most common causes

• Node memory pressure caused by pods collectively using more than the node can provide.
• Disk pressure from image layers, container logs, or ephemeral storage written by pods.
• Inode exhaustion, often from a process creating very large numbers of small files.
• Pods with no resource requests set, which are classed BestEffort and are evicted first.
• Requests set far below actual usage, so scheduling decisions were made on inaccurate information.
• Log files growing without rotation inside containers rather than being written to stdout.

How to diagnose it

1. Read the eviction message: kubectl describe pod POD states which resource was under pressure.
2. Check node conditions: kubectl describe node NODE and look for MemoryPressure, DiskPressure, or PIDPressure.
3. Identify what consumed the resource — for disk, check image cache size and container log volume on the node.
4. Review the QoS class of the evicted pod: kubectl get pod POD -o jsonpath='{.status.qosClass}'. BestEffort pods being evicted first is expected behaviour, not a malfunction.

How to fix it

1. Set realistic resource requests on every workload. Pods without requests are the first to be evicted and the hardest to schedule sensibly.
2. For disk pressure, ensure application logs go to stdout so the node's log rotation handles them, rather than to files inside the container.
3. Add node capacity or reduce workload density if pressure is chronic rather than incidental.
4. Set ephemeral-storage requests and limits for workloads that write significant temporary data.
5. Clean up accumulated evicted pod objects — they hold no resources but obscure the output of kubectl get pods.

Notes

An evicted pod is not restarted in place. If it was created by a Deployment or similar controller, a replacement is scheduled elsewhere; a bare pod is simply gone.

Related

• OOMKilled — Killed by the kernel for exceeding the memory limit
• Pending — Pod accepted but not yet running

Sources

• Kubernetes documentation — Node-pressure Eviction
• Kubernetes documentation — Quality of Service for Pods
• Kubernetes documentation — Resource Management for Pods and Containers