An emptyDir volume is created when a pod starts and deleted when it is removed, and it is shared by every container in the pod. It is the standard way to pass files between an init container and the app, or between an app and a sidecar, without touching persistent storage.
Before you start
You should be comfortable with pods and volumes. This article covers emptyDir and its lifetime.
Step-by-step walkthrough
Step 1: Understand the lifetime
An emptyDir is scoped to the pod: it starts empty, persists across container restarts within the pod, and is removed when the pod is deleted or rescheduled. It is not a durability mechanism, so do not store data that must survive.
Step 2: Share between containers
Two containers mounting the same emptyDir at the same path see the same files. A common pattern is a sidecar that writes logs or config into the volume and the app that reads it, or an init container that prepares data for the app.
Step 3: Choose the medium and set a bound
By default an emptyDir is on the node’s disk, but medium: Memory backs it with tmpfs for speed at the cost of memory. Set sizeLimit so a runaway writer cannot fill the node’s disk or exhaust memory, which is especially important for the memory medium.
Worked scenario
The app and a sidecar share a memory-backed scratch volume.
volumes:
- name: scratch
emptyDir:
medium: Memory
sizeLimit: 64MiWalk through the example
The scratch volume is memory-backed and capped at sixty-four mebibytes, so writes are fast and bounded. Both containers mounting it see the same files. When the pod ends, the volume and its contents disappear, which is the intended ephemeral behavior.
Common mistake
Using emptyDir for data that must persist, then losing it on a reschedule. Another is an unbounded emptyDir, so a large temp file fills the node’s disk and disrupts other pods.
Verify the behavior
Mount the volume in two containers and confirm they see the same files. Delete the pod and confirm the data is gone. Fill the volume past sizeLimit and observe the write failure.
Interview exercise
When would you choose medium: Memory for an emptyDir?
Answer and reasoning
When the scratch data benefits from low latency and fits comfortably in memory, such as a cache directory or a unix socket file shared between containers. The trade is that it consumes the pod’s memory and counts against limits, so keep it small and set a sizeLimit. For larger or less latency-sensitive scratch, the default disk-backed medium is fine.
Continue learning
Compare volumes in Persistent storage and pod lifecycle in Pod lifecycle. Read the Kubernetes emptyDir documentation and try the Kubernetes interview questions.