How to fix Evicted in Kubernetes

KubernetesINTERMEDIATEMEDIUMUpdated Dec 6, 2025· 216 views

Evicted pods were terminated by kubelet due to node resource pressure (memory, disk, or ephemeral storage). Set proper resource limits, clean up disk space, or scale your cluster.

Quick fix

Fixes Evicted

kubectl describe pod <pod-name>
  1. Check why the pod was evicted
  2. Clean up evicted pods
  3. Set proper resource requests and limits
  4. Address memory pressure
kubernetes — error
kubectl describe pod <pod-name>
Evicted

What this error means

Pod eviction occurs when the kubelet proactively terminates pods to reclaim resources on a node experiencing pressure. Unlike application crashes, eviction is an intentional Kubernetes mechanism to maintain node stability. When a node runs low on memory, disk space, or ephemeral storage, kubelet evicts pods based on their Quality of Service (QoS) class and resource usage. BestEffort pods (no resource limits) are evicted first, followed by Burstable pods exceeding their requests, with Guaranteed pods evicted last.

Typical symptoms

  • Pod status shows Evicted with resource pressure reason
  • Events show The node had condition: MemoryPressure or DiskPressure
  • Pods repeatedly evicted and rescheduled
  • Node conditions show MemoryPressure, DiskPressure, or PIDPressure
  • Evicted pods accumulate in namespace (status Evicted but not deleted)
  • Application instability during high memory usage periods

Common causes

  1. Node memory exhausted - pods consuming more than available RAM
  2. Node disk space low - container logs, images, or ephemeral storage filling disk
  3. Pod exceeding ephemeral-storage limits
  4. No resource requests/limits set (BestEffort QoS - evicted first)
  5. Memory leak in application causing gradual consumption increase
  6. Log files growing unbounded without rotation
  7. Too many pods scheduled on undersized nodes

How to fix "Evicted"

1Check why the pod was evicted

Get the eviction reason:

bash
kubectl describe pod <pod-name>

Look for messages like:
- "The node was low on resource: memory"
- "The node was low on resource: ephemeral-storage"
- "Pod ephemeral local storage usage exceeds the total limit"

Check node conditions:

bash
kubectl describe node <node-name> | grep -A 10 Conditions
2Clean up evicted pods

Evicted pods remain as objects taking up etcd space. Remove them:

bash
# Delete all evicted pods in current namespace
kubectl get pods --field-selector=status.phase=Failed | grep Evicted | awk '{print $1}' | xargs kubectl delete pod

# Delete across all namespaces
kubectl get pods -A --field-selector=status.phase=Failed | grep Evicted | awk '{print $1 " -n " $2}' | xargs -L1 kubectl delete pod
3Set proper resource requests and limits

Improve QoS class to reduce eviction priority:

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

QoS Classes:
- Guaranteed (requests = limits): Evicted last
- Burstable (requests < limits): Medium priority
- BestEffort (no requests/limits): Evicted first

Set at least requests to avoid BestEffort status.

4Address memory pressure

For memory-related evictions:

bash
# Check node memory
kubectl top nodes

# Check pod memory usage
kubectl top pods --sort-by=memory

Solutions:
- Increase node memory (larger instance type)
- Add more nodes to distribute load
- Reduce memory limits on less critical pods
- Fix memory leaks in applications
- Use HorizontalPodAutoscaler to scale out instead of up

5Address disk pressure

For disk-related evictions:

bash
# On the node, check disk usage
df -h
du -sh /var/lib/docker/*
du -sh /var/lib/containerd/*
du -sh /var/log/*

Clean up:

bash
# Remove unused images
crictl rmi --prune

# Clean container logs (careful - loses logs)
truncate -s 0 /var/lib/docker/containers/*/*-json.log

Set ephemeral-storage limits on pods to prevent unbounded growth.

6Use Priority Classes for critical workloads

Protect important pods from eviction:

yaml
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000
globalDefault: false
description: "High priority for critical services"
---
apiVersion: v1
kind: Pod
metadata:
  name: critical-pod
spec:
  priorityClassName: high-priority
  containers:
  - name: app
    image: myapp

Higher priority pods are evicted after lower priority ones.

Advanced notes

Eviction thresholds are configurable via kubelet flags:
- --eviction-hard: Immediate eviction (default: memory.available<100Mi, nodefs.available<10%)
- --eviction-soft: Eviction after grace period
- --eviction-soft-grace-period: How long to wait before soft eviction

For I/O-intensive workloads, kernel page cache can trigger false memory pressure. The cache is reclaimable but kubelet may not account for it correctly. Setting memory requests = limits helps prevent this.

Monitor eviction patterns with:

bash
kubectl get events --field-selector reason=Evicted

Consider cluster autoscaler to add nodes automatically when resource pressure increases.

Frequently asked questions

What does "Evicted" mean?
Pod eviction occurs when the kubelet proactively terminates pods to reclaim resources on a node experiencing pressure. Unlike application crashes, eviction is an intentional Kubernetes mechanism to maintain node stability. When a node runs low on memory, disk space, or ephemeral storage, kubelet evicts pods based on their Quality of Service (QoS) class and resource usage.
How do I fix "Evicted"?
Evicted pods were terminated by kubelet due to node resource pressure (memory, disk, or ephemeral storage). Set proper resource limits, clean up disk space, or scale your cluster.
What causes "Evicted"?
Node memory exhausted - pods consuming more than available RAM Node disk space low - container logs, images, or ephemeral storage filling disk Pod exceeding ephemeral-storage limits
Is the "Evicted" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading