Ephemeral volumes live for the life of a Pod: delete the Pod and the data disappears, move the Pod and the cache is rebuilt. They are useful for caches, intermediate files, shared logs, and build spaces, but not for databases or data that must survive Pod replacement.

Common use cases

  • Runtime caches and temporary files
  • Intermediate results in data-processing jobs
  • Data shared between a sidecar and the main container
  • Scratch space for CI and batch jobs

emptyDir and memory-backed volumes

An emptyDir is created when the Pod is scheduled and released when the Pod is deleted. Set an explicit size limit:

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

For latency-sensitive data, use memory-backed storage:

emptyDir:
  medium: Memory
  sizeLimit: 512Mi

This consumes node memory. Keep memory-backed emptyDir small; it is not a place for a large cache.

Sidecar sharing

The main container can write logs while a sidecar reads them:

containers:
  - name: app
    image: my-app:1.0.0
    volumeMounts:
      - name: shared
        mountPath: /var/log/app
  - name: shipper
    image: busybox:1.36
    command: ["sh", "-c", "tail -F /var/log/app/app.log"]
    volumeMounts:
      - name: shared
        mountPath: /var/log/app

Use predictable paths. Cleanup scripts are only reliable when locations are stable.

Build workspaces and cache warm-up

CI and build jobs can use an emptyDir as a workspace:

volumes:
  - name: workspace
    emptyDir: {}
volumeMounts:
  - name: workspace
    mountPath: /workspace

Upload artifacts you care about to object storage or a persistent volume before the Pod exits.

You can also pre-populate a cache with an init container:

initContainers:
  - name: warm-cache
    image: busybox:1.36
    command: ["sh", "-c", "echo warm > /cache/seed.txt"]
    volumeMounts:
      - name: cache
        mountPath: /cache
containers:
  - name: app
    image: my-app:1.0.0
    volumeMounts:
      - name: cache
        mountPath: /cache

Generic ephemeral volumes

When you need more capacity or a faster backend, a generic ephemeral volume creates a short-lived PVC through a StorageClass. The claim follows the Pod lifecycle:

volumes:
  - name: cache
    ephemeral:
      volumeClaimTemplate:
        spec:
          accessModes: ["ReadWriteOnce"]
          storageClassName: fast-ssd
          resources:
            requests:
              storage: 5Gi

This fits batch jobs and short-lived work. Long-lived data still belongs in a PVC or database.

Treat ephemeral storage as a budget

emptyDir.sizeLimit is a soft limit enforced by the kubelet. The scheduler also needs ephemeral-storage requests and limits to place Pods predictably:

resources:
  requests:
    cpu: "100m"
    memory: "256Mi"
    ephemeral-storage: "1Gi"
  limits:
    cpu: "500m"
    memory: "512Mi"
    ephemeral-storage: "2Gi"

Container logs count against node ephemeral storage. Clusters without log rotation or centralized collection often hit disk pressure before the application cache actually fills.

Observe disk pressure and eviction

When Pods are evicted repeatedly, inspect the node and events first:

kubectl describe pod <pod-name>
kubectl get events -A
kubectl describe node <node> | rg -n "ephemeral-storage|Allocatable"
kubectl top pod -A

Inside a Pod, check filesystem usage:

kubectl exec -it <pod-name> -- df -h

Security boundary

Ephemeral volumes live on the node filesystem. Avoid writing secrets or regulated data. If that is unavoidable, encrypt first, use memory-backed storage, and keep the capacity small.

When not to use ephemeral storage

  • Databases or data that must survive Pod restarts
  • Audit logs and compliance-retained data
  • User uploads or business-critical files

FAQ

Q: Why is a Pod Pending? A: The node may lack ephemeral storage, or the Pod’s ephemeral-storage request cannot fit.

Q: Why is a Pod Evicted? A: Usually node disk pressure. Check the ephemeral volume, logs, and image cache.

Q: Why can a size-limited volume still hurt the node? A: emptyDir.sizeLimit is soft. Without explicit limits, the kubelet may evict Pods under node pressure.

Q: Generic ephemeral volume or PVC? A: Use a generic ephemeral volume for data tied to a Pod lifecycle. Use a normal PVC for data that must survive it.

Pre-flight checklist

  • emptyDir has a sizeLimit
  • Containers have ephemeral-storage requests/limits
  • Cache paths are fixed and cleanup is reliable
  • Build artifacts are uploaded before Pod exit
  • Logs are rotated or collected centrally
  • Sensitive data is not written to node-local storage

References