Ephemeral vs persistent volumes — the fundamental distinction

The fundamental distinction in Kubernetes storage is between ephemeral volumes (which live with the Pod) and persistent volumes (which outlive the Pod). This lesson establishes the distinction at every level — lifecycle, semantics, and operational discipline.

What ephemeral means

An ephemeral volume is created when the Pod is created and destroyed when the Pod is destroyed. There is no PVC; the volume is declared in the Pod’s spec:

apiVersion: v1
kind: Pod
metadata:
  name: app
spec:
  containers:
  - name: app
    image: app:v1
    volumeMounts:
    - name: scratch
      mountPath: /scratch
  volumes:
  - name: scratch
    emptyDir: {}

When this Pod is created, the kubelet creates an emptyDir (an empty directory on the node’s filesystem). When the Pod is deleted, the emptyDir is deleted.

The lifecycle is bound to the Pod. The data does not survive:

• Pod restart (the container restarts but the data is preserved unless the Pod is deleted and recreated).
• Pod deletion (the data is gone).
• Node failure (if the Pod is rescheduled to another node, the data is gone).
• Cluster failure (the data is gone).

What persistent means

A persistent volume outlives the Pod. The user creates a PVC; the PVC is bound to a PV; the Pod mounts the PV. When the Pod is deleted, the PVC and PV remain:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data
spec:
  accessModes: ["ReadWriteOnce"]
  storageClassName: ssd
  resources:
    requests:
      storage: 100Gi

The data survives:

• Pod restart (the same PVC is rebound to the new Pod).
• Pod deletion (the PVC and PV remain; data is intact).
• Node failure (if the Pod is rescheduled, the PVC is rebound).
• Cluster failure (the data is on the storage backend, not on the cluster’s etcd).

The lifecycle comparison

flowchart LR
    subgraph ephemeral
      A1[Pod created] --> A2[emptyDir created]
      A2 --> A3[Pod deleted]
      A3 --> A4[emptyDir deleted]
    end
    subgraph persistent
      B1[PVC created] --> B2[PV provisioned]
      B2 --> B3[Pod mounts PV]
      B3 --> B4[Pod deleted]
      B4 --> B5[PVC remains, data intact]
      B5 --> B6[New Pod mounts same PVC]
    end

The ephemeral volume’s lifecycle is bound to the Pod; the persistent volume’s lifecycle is bound to the PVC. The Pod comes and goes; the PVC stays.

What survives what

The production rule: any data that must survive Pod deletion must be on a persistent volume. Any data that can be reconstructed (cache, scratch, derived state) can be ephemeral.

The cost of persistence

Persistent volumes are not free:

• Latency: persistent volumes go through the storage backend (cloud block, network filesystem), which adds latency vs local SSD.
• Cost: persistent volumes are billed per GB per hour; ephemeral storage on the node’s local disk is “free” (within the node’s capacity).
• Operational complexity: PVCs require binding, provisioning, attachment, mounting. emptyDir is just a directory.
• Snapshot and backup: persistent volumes can be snapshotted and backed up; ephemeral volumes cannot.

The trade-off is clear: ephemeral is cheaper and faster; persistent is durable. Production workloads that need state pay the persistence cost; workloads that do not need state use ephemeral and save the cost.

The hybrid pattern

Some workloads need both: persistent state plus ephemeral scratch. The standard pattern:

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

The data volume is persistent (the application’s state). The scratch and cache volumes are ephemeral (the application’s transient state). The Pod spec is explicit about which is which.

Quiz

Production discipline

• Ephemeral for scratch, persistent for state. The Pod spec encodes the distinction by volume type and mount path.
• Never use emptyDir for stateful data. The data loss is silent until the Pod is deleted.
• The volume name in the Pod spec is documentation. Match the application’s terminology.
• Hybrid patterns are normal. Most production Pods have both persistent and ephemeral volumes; the Pod spec makes the distinction explicit.