In a Pod spec you can mount an emptyDir volume or mount a PersistentVolumeClaim. Explain the lifecycle difference between the two and when each is the right choice.

juniormust knowfreq 72%

answer

emptyDir dies with the Pod, not with the container
PVC outlives Pod, Deployment, rollout
Pod → PVC → PV → real storage
medium: Memory = tmpfs, counts against memory
sizeLimit or a writer fills the node

basics

~20 s

An emptyDir is created when the Pod is placed on a node and deleted with the Pod, so it survives container restarts but not rescheduling. A PersistentVolumeClaim points at storage whose lifetime is independent of the Pod, so data survives deletion and rescheduling.

solid answer

~50 s

Both appear in spec.volumes, but their lifetimes differ.

emptyDir is a Pod-scoped scratch directory. Kubelet creates it when the Pod is assigned to a node and deletes it, with all contents, when the Pod is removed from that node. It survives a container crash-and-restart inside the same Pod, but not a reschedule — a new Pod gets an empty directory again. Use it for caches, scratch space, and sharing files between containers in one Pod.

PersistentVolumeClaim is an indirection: the Pod references a claim, the claim is bound to a PersistentVolume, and that PV represents storage the cluster manages independently. Delete the Pod, reschedule it, roll the Deployment — the data stays. Use it for databases, uploads, anything whose loss is an incident.

The API shape mirrors the concept: emptyDir is configured inline in the Pod; a PVC is a separate object the Pod merely names, so storage and workload have separate lifecycles.

Both appear in `spec.volumes`, but their lifetimes differ. **emptyDir** is a Pod-scoped scratch directory. Kubelet creates it when the Pod is assigned to a node and deletes it, with all contents, when the Pod is removed from that node. It survives a container crash-and-restart inside the same Pod, but not a reschedule — a new Pod gets an empty directory again. Use it for caches, scratch space, and sharing files between containers in one Pod. **PersistentVolumeClaim** is an indirection: the Pod references a claim, the claim is bound to a PersistentVolume, and that PV represents storage the cluster manages independently. Delete the Pod, reschedule it, roll the Deployment — the data stays. Use it for databases, uploads, anything whose loss is an incident. The API shape mirrors the concept: emptyDir is configured inline in the Pod; a PVC is a separate object the Pod merely names, so storage and workload have separate lifecycles.

code

yaml · 20 lines

yaml

apiVersion: v1
kind: Pod
metadata:
  name: app
spec:
  containers:
  - name: app
    image: app:1.0
    volumeMounts:
    - name: cache
      mountPath: /var/cache/app
    - name: data
      mountPath: /var/lib/app
  volumes:
  - name: cache
    emptyDir:
      sizeLimit: 1Gi
  - name: data
    persistentVolumeClaim:
      claimName: app-data

go deeper

for a junior

Give the crisp lifetime rule (emptyDir = Pod lifetime, PVC = independent) and one example use of each.

for a middle

Add that emptyDir survives container restarts but not rescheduling, mention medium: Memory and sizeLimit, and describe the Pod→PVC→PV indirection.

for a senior

Discuss why the PVC surviving deletion is deliberate, the node-disk risk of unbounded emptyDir, and when generic ephemeral volumes are the better middle ground.

for a principal

Frame it as data-durability boundaries: which state is recoverable and which is not, and how that drives whether a workload uses scratch, per-replica claims, or an external service.

The core distinction: who owns the lifetime

Everything a Pod mounts is listed under spec.volumes, so at first glance an emptyDir and a persistentVolumeClaim look like siblings. They are not. The question that separates them is: when this Pod ceases to exist, does the data cease to exist too?

For emptyDir, yes. Kubelet allocates a directory on the node the moment the Pod is bound to that node, mounts it into whichever containers ask for it, and removes it — irreversibly — when the Pod is deleted or evicted from the node. There is no snapshot, no reclaim, no recovery.

For a PersistentVolumeClaim, no. The claim is a first-class namespaced object; the PersistentVolume it binds to is a cluster-scoped object representing real storage. Both outlive the Pod. That is the whole point of the abstraction.

What emptyDir does and does not survive

Container restart within the Pod: data survives. If the process crashes and kubelet restarts the container, the same directory is remounted. This is why emptyDir is fine for a cache that would be expensive but not fatal to lose.
Pod deletion, eviction, node drain, rescheduling, rolling update: data is gone. A Deployment rollout replaces Pods, so every rollout wipes every emptyDir.
Node reboot: effectively gone — the Pod itself does not survive as the same Pod object on the node.

Two options are worth knowing: emptyDir.medium: Memory backs the directory with tmpfs (fast, RAM-consuming, counted against the Pod's memory limit, cleared on restart), and emptyDir.sizeLimit caps how much a Pod may write before it is evicted — without it, a runaway writer can fill the node's disk and disrupt every other Pod on that node.

The other classic emptyDir use is sharing between containers of the same Pod: an init container downloads or renders content into the emptyDir, and the main container serves it; or a sidecar tails a file the app writes there.

What the PVC indirection buys

The chain is Pod → PVC → PV → real storage. Each hop exists for a reason:

The Pod names only a claim, so the manifest carries no disk IDs, no NFS server addresses, no cloud specifics. The same manifest deploys anywhere.
The PVC is the developer-facing request: how much space, which access mode, which class. It lives in the application's namespace and is subject to that namespace's quotas.
The PV is the cluster-facing resource, created either by an administrator (static provisioning) or automatically by a provisioner (dynamic provisioning). It holds the messy details: the volume handle, the node affinity, the reclaim policy.

Because the PVC is a separate object, deleting the Deployment does not delete the data. That is a feature — and a trap for people who expect kubectl delete -f . to clean everything up. It also means the PVC's own deletion is the moment of truth, governed by the PV's reclaim policy.

Choosing

Use emptyDir when losing the data costs nothing but time: build scratch space, downloaded artifacts, a rendering cache, a Unix socket directory, temp files for image processing, a shared handoff between init and main containers.

Use a PVC when losing the data is an incident: database files, user uploads, a message broker's log, anything a customer would notice. Note that using a PVC does not by itself make a Deployment safely stateful — several replicas sharing one ReadWriteOnce claim will not schedule across nodes, which is why per-replica claims and StatefulSets exist.

There is a middle ground: generic ephemeral volumes, declared inline in the Pod with ephemeral.volumeClaimTemplate. These give you real provisioned storage (any CSI driver, any size) whose lifetime is still tied to the Pod: the PVC is created with the Pod and garbage-collected with it. That is the right answer for "I need 200Gi of fast scratch that emptyDir cannot give me, but I do not want it to outlive the Pod".

A quick way to reason in an interview

Ask yourself two questions in order: does the data need to survive this Pod? If no, emptyDir (or an ephemeral volume if you need size, a specific class, or block mode). If yes, a PVC — and then the follow-up question becomes what happens to the underlying volume when the claim is finally deleted, which is the reclaim policy's job.

## The core distinction: who owns the lifetime Everything a Pod mounts is listed under `spec.volumes`, so at first glance an `emptyDir` and a `persistentVolumeClaim` look like siblings. They are not. The question that separates them is: *when this Pod ceases to exist, does the data cease to exist too?* For **emptyDir**, yes. Kubelet allocates a directory on the node the moment the Pod is bound to that node, mounts it into whichever containers ask for it, and removes it — irreversibly — when the Pod is deleted or evicted from the node. There is no snapshot, no reclaim, no recovery. For a **PersistentVolumeClaim**, no. The claim is a first-class namespaced object; the PersistentVolume it binds to is a cluster-scoped object representing real storage. Both outlive the Pod. That is the whole point of the abstraction. ## What emptyDir does and does not survive - **Container restart within the Pod:** data survives. If the process crashes and kubelet restarts the container, the same directory is remounted. This is why `emptyDir` is fine for a cache that would be expensive but not fatal to lose. - **Pod deletion, eviction, node drain, rescheduling, rolling update:** data is gone. A Deployment rollout replaces Pods, so every rollout wipes every emptyDir. - **Node reboot:** effectively gone — the Pod itself does not survive as the same Pod object on the node. Two options are worth knowing: `emptyDir.medium: Memory` backs the directory with tmpfs (fast, RAM-consuming, counted against the Pod's memory limit, cleared on restart), and `emptyDir.sizeLimit` caps how much a Pod may write before it is evicted — without it, a runaway writer can fill the node's disk and disrupt every other Pod on that node. The other classic emptyDir use is **sharing between containers of the same Pod**: an init container downloads or renders content into the emptyDir, and the main container serves it; or a sidecar tails a file the app writes there. ## What the PVC indirection buys The chain is Pod → PVC → PV → real storage. Each hop exists for a reason: - The **Pod** names only a claim, so the manifest carries no disk IDs, no NFS server addresses, no cloud specifics. The same manifest deploys anywhere. - The **PVC** is the developer-facing request: how much space, which access mode, which class. It lives in the application's namespace and is subject to that namespace's quotas. - The **PV** is the cluster-facing resource, created either by an administrator (static provisioning) or automatically by a provisioner (dynamic provisioning). It holds the messy details: the volume handle, the node affinity, the reclaim policy. Because the PVC is a separate object, deleting the Deployment does not delete the data. That is a feature — and a trap for people who expect `kubectl delete -f .` to clean everything up. It also means the PVC's own deletion is the moment of truth, governed by the PV's reclaim policy. ## Choosing Use **emptyDir** when losing the data costs nothing but time: build scratch space, downloaded artifacts, a rendering cache, a Unix socket directory, temp files for image processing, a shared handoff between init and main containers. Use a **PVC** when losing the data is an incident: database files, user uploads, a message broker's log, anything a customer would notice. Note that using a PVC does not by itself make a Deployment safely stateful — several replicas sharing one ReadWriteOnce claim will not schedule across nodes, which is why per-replica claims and StatefulSets exist. There is a middle ground: **generic ephemeral volumes**, declared inline in the Pod with `ephemeral.volumeClaimTemplate`. These give you real provisioned storage (any CSI driver, any size) whose lifetime is still tied to the Pod: the PVC is created with the Pod and garbage-collected with it. That is the right answer for "I need 200Gi of fast scratch that emptyDir cannot give me, but I do not want it to outlive the Pod". ## A quick way to reason in an interview Ask yourself two questions in order: *does the data need to survive this Pod?* If no, emptyDir (or an ephemeral volume if you need size, a specific class, or block mode). If yes, a PVC — and then the follow-up question becomes what happens to the underlying volume when the claim is finally deleted, which is the reclaim policy's job.

Does an emptyDir survive a container crash?
Yes. The directory belongs to the Pod, not the container, so kubelet remounts the same data when it restarts a crashed container in place. What destroys it is the Pod leaving the node — deletion, eviction, drain, or a rolling update that replaces the Pod object.
You delete a Deployment that mounted a PersistentVolumeClaim. Is the data gone?
No. The PVC is a separate object and is not garbage-collected with the Deployment, so the claim and its bound PersistentVolume remain and a new Deployment can mount them again. The data is only at risk once the PVC itself is deleted, and even then the outcome depends on the PV's reclaim policy — Delete destroys the backing volume, Retain keeps it.
What is `emptyDir.medium: Memory` and when would you use it?
It backs the volume with tmpfs, so reads and writes hit RAM instead of the node's disk. It is useful for very hot scratch data and for keeping sensitive material off disk. The cost is that the space consumed counts toward the Pod's memory limit, so a large write can get the Pod OOM-killed.

emptyDir is the desk you are given for the day and cleared when you leave; a PVC is a locker with your name on it that is still there next week, even if you sit at a different desk.

saying these in an interview costs you the question

Saying emptyDir is deleted when a container restarts
Assuming a PVC is deleted along with the Deployment that used it
Believing a PVC alone makes a multi-replica Deployment safely stateful
Using hostPath as 'persistent storage' instead of a PVC
Omitting sizeLimit and treating emptyDir as unlimited node disk

In a Pod spec you can mount an emptyDir volume or mount a PersistentVolumeClaim. Explain the lifecycle difference between the two and when each is the right choice.

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

The core distinction: who owns the lifetime

What emptyDir does and does not survive

What the PVC indirection buys

Choosing

A quick way to reason in an interview

▾common follow-ups3 questions

▾analogy~20 s

▾red flags5 flags

§ context

▾related questions5 questions

▾related topics3 topics

The core distinction: who owns the lifetime

What emptyDir does and does not survive

What the PVC indirection buys

Choosing

A quick way to reason in an interview

answer

go deeper

context