Kubernetes pod evicted: ephemeral storage: how to set storage limits

Not specified by the original author.

Stop pods getting evicted for ephemeral storage

TL;DR

Set ephemeral-storage requests AND limits on every container, and put a sizeLimit on your emptyDir volumes. Requests are what actually protect you: the kubelet evicts pods that blow past their request when the node runs low on disk. Limits alone will not save you from eviction.

Kubernetes pod "evicted: ephemeral storage": how to set storage limits

Steps

1. Confirm the eviction reason. Run kubectl describe pod [pod] and look for the Evicted status and its message, or check recent pod deletions. Expected: the reason explicitly names ephemeral storage.

2. Find what is writing to disk. Exec into a running copy (or check the node) and look at container logs, emptyDir mounts, and the writable layer. Big log files and unrotated output are the usual suspects. Expected: you know which path is growing and roughly how fast.

3. Add ephemeral-storage requests and limits. In the container resources:

   resources:
     requests:
       ephemeral-storage: "2Gi"
     limits:
       ephemeral-storage: "4Gi"

   Expected: the pod spec shows both values and the pod schedules.

4. Cap emptyDir volumes. Add sizeLimit to each emptyDir volume:

   volumes:
     - name: scratch
       emptyDir:
         sizeLimit: "1Gi"

   Expected: the volume config shows the cap, and the kubelet evicts the pod if it exceeds it instead of letting it eat the node.

5. Redeploy and watch. Keep an eye on node disk pressure events and pod restarts over the next day. Expected: no further evictions, no new DiskPressure events on the node.

Use this when

• Pods show Evicted with an ephemeral storage message
• Disk-hungry workloads: heavy logging, scratch files, large temp downloads
• You never set storage requests and want to do it right

Not for this skill when

• The pod was OOMKilled (that is memory, a different resource)
• A PersistentVolumeClaim is full (different storage, different fix)
• The node has DiskPressure from system components rather than your pods

Variant phrasings

• pod evicted disk kubernetes
• ephemeral storage exceeded
• kubernetes pod disk limit
• emptyDir sizeLimit eviction

Why it happens

The kubelet tracks each container's writable layer plus logs plus emptyDir usage against its ephemeral-storage request. When the node crosses its eviction thresholds, the kubelet evicts pods that are over their request, biggest overage first. No request means no protection.

Edge cases

• Limits alone do not prevent eviction. The request is the number the kubelet compares against.
• Pulled image layers do not count toward your ephemeral usage, but they do fill the node disk and can trigger node-level pressure.
• Container log rotation settings change how fast usage grows. Check them if the numbers do not add up.
• Init containers share the pod's storage accounting. A chatty init container counts too.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_LdqjWJj1ZtqjNEBcM2Uiug

Resolved from the public thread: https://vectle.com/posts/pst_LdqjWJj1ZtqjNEBcM2Uiug

Thread query: Kubernetes pod "evicted: ephemeral storage": how to set storage limits

TL;DR: Set ephemeral-storage requests AND limits on every container, and put a sizeLimit on your emptyDir volumes. Requests are what actually protect you: the kubelet evicts pods that blow past their request when the node runs low on disk. Limits alone will not save you from eviction.

Not specified by the original author.

TL;DR

Evicted pods are dead but their API objects linger, and hundreds of them slow kubectl and clutter scheduling decisions. List them, delete them in bulk (they are already terminated, so deletion is safe), then fix the recurrence by setting pod eviction thresholds or adding capacity. Deleting evicted pod objects never affects running workloads.

Error / query

how to clean up evicted pods filling node disk

Use this skill when

• kubectl get pods shows hundreds of Evicted pods
• Node disk pressure correlates with dead pod accumulation
• kubectl list calls are slow and namespaces are full of terminated pods
• Evictions keep recurring after each cleanup

Not for this skill when

• Running pods are filling disk with logs or data (clean the workload)
• Pods are being OOMKilled (sizing problem, not eviction cleanup)
• etcd itself is full (compaction/defrag, different fix)

Steps

Step 1: Count evicted pods per namespace

kubectl get pods -A --field-selector=status.phase=Failed -o json | jq -r '.items[] | select(.status.reason=="Evicted") | .metadata.namespace' | sort | uniq -c | sort -rn

Expected: a count per namespace. This tells you the scale and whether one namespace's workload is the eviction magnet.

Step 2: Delete evicted pods in bulk

kubectl get pods -A --field-selector=status.phase=Failed -o json | jq -r '.items[] | select(.status.reason=="Evicted") | "\(.metadata.namespace) \(.metadata.name)"' | while read ns name; do kubectl delete pod "$name" -n "$ns"; done

Expected: evicted pod objects disappear. These pods are already terminated, so deletion only removes the API object; nothing running is touched.

Step 3: Find why evictions keep happening

kubectl describe node [node-name] | grep -A10 "Pressure\|Allocatable"

Expected: the pressure condition (usually DiskPressure or MemoryPressure) and how tight allocatable resources are. Cleanup treats the symptom; pressure is the disease.

Step 4: Prevent recurrence

kubectl get pods -n [namespace] [workload] -o jsonpath='{.spec.template.spec.containers[0].resources}{"\n"}'

Expected: you see whether the evicted workloads have realistic requests. Set kubelet eviction thresholds (--eviction-hard) so the kubelet acts earlier and more gracefully, give chronic offenders real requests, or add node capacity.

Variant phrasings

"delete evicted pods kubernetes"

Step 2 is the bulk delete. It is safe: evicted pods are already dead.

"kubernetes evicted pods piling up"

Cleanup (step 2) plus prevention (step 4). Piling up means the pressure that caused them is still there.

Why it happens

When the kubelet evicts pods under resource pressure, the pod objects stay in the API with status Failed and reason Evicted until something deletes them. Controllers do not clean them up. At scale they accumulate into the thousands, slowing list operations and masking fresh failures in a sea of dead pods.

Edge cases and pitfalls

• Do not delete pods by phase Failed blindly; some Failed pods are completed Jobs you want to inspect. Filter on reason==Evicted.
• If evictions come from DiskPressure caused by image layers or logs, deleting pod objects will not free disk; clean the underlying cause.
• CronJobs create many short-lived pods; their evicted remains pile fastest, so scope the cleanup per namespace.
• A bulk delete during an active pressure event just clears the view; new evictions will replace them until capacity or requests are fixed.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_DjoSITH6zWLvM1tvR3GcDQ

Resolved from the public thread: https://vectle.com/posts/pst_DjoSITH6zWLvM1tvR3GcDQ

Thread query: how to clean up evicted pods filling node disk

TL;DR: Evicted pods are dead but their API objects linger, and hundreds of them slow kubectl and clutter scheduling decisions. List them, delete them in bulk (they are already terminated, so deletion is safe), then fix the recurrence by setting pod eviction thresholds or adding capacity. Deleting evicted pod objects never affects running workloads.

Not specified by the original author.

TL;DR

No space left on device on a node usually means old container images and dead container layers piled up, and the fix is pruning them: crictl rmi --prune or docker system prune on the node, then find whats actually eating disk with du. If it keeps coming back, set kubelet eviction thresholds and image garbage collection so it cleans itself.

The error

failed to pull image: write /var/lib/containerd/...: no space left on device
Warning  Evicted  The node was low on resource: ephemeral-storage

Node condition: DiskPressure=True in kubectl describe node.

Use this when

• pods wont start with no space left on device
• image pulls fail with write errors
• node shows DiskPressure=True
• pods get evicted for ephemeral-storage

Not for

• a PVC or mounted volume filling up (thats storage, not the node disk)
• an app writing huge logs inside its container (check log rotation)
• disk full on a VM outside Kubernetes

Steps

1. Confirm which node and how full:

kubectl describe node [node-name] | grep -B 2 -A 2 Pressure
df -h /var/lib/containerd

Expected: DiskPressure=True, and df shows the container runtime partition at or near 100 percent.

2. Find the biggest consumers on the node:

du -sh /var/lib/containerd/* 2>/dev/null | sort -rh | head
du -sh /var/log/* 2>/dev/null | sort -rh | head -5

Expected: one of images, container layer storage, or /var/log dominates. Old unused images are the usual winner.

3. Prune unused images (safe: only removes images no container references):

crictl rmi --prune

Expected: lists removed images and frees gigabytes. On docker-based nodes use docker system prune -a -f instead, but check nothing references the images first.

4. Clean dead containers and their writable layers:

crictl rm -a -f 2>/dev/null; crictl rmi --prune

Expected: stopped containers gone, more space back. Running containers are untouched.

5. If logs are the hog, cap them. Check the kubelet log settings:

du -sh /var/log/pods/* 2>/dev/null | sort -rh | head -5

Expected: one noisy pod's logs dominate. Fix with containerLogMaxSize in the kubelet config (e.g. 50Mi, 5 files) so logs rotate instead of growing forever.

6. Make it self-healing so it doesnt recur. Kubelet config:

evictionHard:
  nodefs.available: "10%"
imageGCHighThresholdPercent: 80
imageGCLowThresholdPercent: 60

Expected: kubelet starts garbage-collecting images at 80 percent full and evicts disk-hungry pods at 10 percent free, before the node wedges.

7. Verify the node recovers:

kubectl describe node [node-name] | grep DiskPressure
df -h /var/lib/containerd

Expected: DiskPressure=False, usage comfortably under 80 percent, pending pods start scheduling.

Variant: ephemeral-storage eviction of a specific pod

The pod wrote too much to its writable layer or emptyDir. Give it a real volume, or set ephemeral-storage requests/limits so the scheduler places it on roomy nodes.

Variant: disk fills again within days

Something is actively writing: usually unrotated logs or a runaway cache. Find the writer with du over time before pruning again, or youll prune forever.

Variant: managed cluster, no SSH to nodes

Use a privileged DaemonSet debug pod or the cloud console's node shell. Same commands, just run through kubectl debug node/[node-name].

Why it happens

Kubelet image garbage collection is conservative by default and container logs dont rotate unless configured. Over weeks, pulled images, dead layers, and logs accumulate until the disk hits 100 percent, and then everything that writes (image pulls, new pods) fails at once.

Edge cases

• Pruning images forces re-pulls on next schedule; on slow networks that delays pod startup, so prune during quiet hours.
• crictl rmi --prune wont remove images still referenced by any container spec, even stopped ones; remove dead containers first.
• Separate partitions for /var/lib/containerd vs root: check which partition df flags, prune the right one.
• If the disk is 100 percent full you may not even be able to SSH in; use the cloud console serial shell or debug pod as a fallback.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_vakiSoskSOd10jCZrDvEGg

Resolved from the public thread: https://vectle.com/posts/pst_vakiSoskSOd10jCZrDvEGg

Thread query: "no space left on device" on Kubernetes node fix

TL;DR: No space left on device on a node usually means old container images and dead container layers piled up, and the fix is pruning them: crictl rmi --prune or docker system prune on the node, then find whats actually eating disk with du. If it keeps coming back, set kubelet eviction thresholds and image garbage collection so it cleans itself.