Kubernetes emptyDir volumes: Use cases and examples

Before diving into emptyDir specifically, here is a quick overview of where it fits in the Kubernetes volume landscape:

What is emptyDir?

An emptyDir volume is created fresh when a pod is assigned to a node. It exists for the entire lifetime of that pod and is deleted when the pod is deleted.

The key distinction is that emptyDir is pod-scoped, not container-scoped. If a container inside the pod crashes and restarts, the emptyDir volume and all its data are still there when the container comes back up. The data is only lost when the entire pod is deleted. This makes emptyDir useful for data that needs to survive container restarts but does not need to outlive the pod.

By default, emptyDir uses the node's disk. You can optionally back it with node RAM for faster access.

Common use cases

• Shared scratch space between containers in the same pod: A main application container writes files to an emptyDir and a sidecar container reads from the same directory. This is a common pattern for log shipping: the application writes logs to /var/log/app and a Fluentd or Filebeat sidecar reads from the same path and forwards them to a logging backend.
• Caching downloaded assets: A pod that processes files can download them into an emptyDir in an init container and then process them in the main container, avoiding repeated downloads across processing steps.
• Temporary file processing in a batch pipeline: Intermediate files generated during a multi-stage processing job can live in an emptyDir between stages. When the pod completes, the files are cleaned up automatically.
• Checkpointing long computations: A computation that runs in stages can write checkpoints to an emptyDir so that if a container crashes mid-computation, it can resume from the last checkpoint rather than starting over.

Basic emptyDir example

1apiVersion: v1
2kind: Pod
3metadata:
4  name: emptydir-pod
5spec:
6  containers:
7  - name: busybox
8    image: busybox
9    command: ["sh", "-c", "while true; do sleep 3600; done"]
10    volumeMounts:
11    - mountPath: /demo
12      name: demo-volume
13  volumes:
14  - name: demo-volume
15    emptyDir: {}

1kubectl create -f pod.yaml
2kubectl get pods

Exec into the pod and create a file:

1kubectl exec -it emptydir-pod -- sh

1cd /demo
2touch test
3ls

Expected output:

1test

Exit the pod and verify the file exists from outside:

1kubectl exec -it emptydir-pod -- ls /demo

Expected output:

1test

Delete the pod:

1kubectl delete pod emptydir-pod --force --grace-period=0

The emptyDir and all its contents are deleted with the pod. There is nothing to clean up manually.

Sharing an emptyDir between two containers

This example shows a sidecar pattern. The main container writes a timestamp to a shared log directory every five seconds. The sidecar container reads from the same directory.

1apiVersion: v1
2kind: Pod
3metadata:
4  name: shared-volume-pod
5spec:
6  containers:
7  - name: writer
8    image: busybox
9    command: ["sh", "-c", "while true; do date >> /shared/log.txt; sleep 5; done"]
10    volumeMounts:
11    - mountPath: /shared
12      name: shared-data
13  - name: reader
14    image: busybox
15    command: ["sh", "-c", "while true; do cat /shared/log.txt; sleep 10; done"]
16    volumeMounts:
17    - mountPath: /shared
18      name: shared-data
19  volumes:
20  - name: shared-data
21    emptyDir: {}

1kubectl create -f shared-volume-pod.yaml

Check the reader container's logs to see the timestamps being written by the writer container:

1kubectl logs shared-volume-pod -c reader

Expected output:

1Thu Jan 15 10:23:01 UTC 2026
2Thu Jan 15 10:23:06 UTC 2026
3Thu Jan 15 10:23:11 UTC 2026

Both containers share the same /shared directory via the emptyDir volume. Data written by one is immediately visible to the other.

Memory-backed emptyDir

Set medium: Memory to back the emptyDir with node RAM instead of disk. This gives you tmpfs storage, which is significantly faster than disk for workloads that need very fast temporary storage.

1apiVersion: v1
2kind: Pod
3metadata:
4  name: memory-volume-pod
5spec:
6  containers:
7  - name: busybox
8    image: busybox
9    command: ["sh", "-c", "while true; do sleep 3600; done"]
10    resources:
11      limits:
12        memory: 256Mi
13    volumeMounts:
14    - mountPath: /cache
15      name: cache-volume
16  volumes:
17  - name: cache-volume
18    emptyDir:
19      medium: Memory
20      sizeLimit: 128Mi

Two important things to note with memory-backed emptyDir:

The volume size counts against the container's memory limit. In the example above, the container has a 256Mi memory limit. If the emptyDir uses 128Mi of that, only 128Mi remains for the application itself. Size it carefully.

Use sizeLimit to cap how much RAM the emptyDir can consume. Without it, the volume can grow until it hits the container's memory limit, which will trigger an OOMKilled event.

1kubectl create -f memory-volume-pod.yaml
2kubectl exec -it memory-volume-pod -- df -h /cache

Expected output:

1Filesystem      Size  Used Avail Use% Mounted on
2tmpfs           128M     0  128M   0% /cache