Why persistent storage matters in Kubernetes - Visual Breakdown

Process Flow - Why persistent storage matters in Kubernetes

Pod starts

↓

Pod uses ephemeral storage

↓

Pod crashes or restarts

↓

Ephemeral data lost

↓

Persistent Volume attached

↓

Pod writes data to Persistent Volume

↓

Pod restarts

↓

Data still available

↓

Application continues smoothly

This flow shows how pods without persistent storage lose data on restart, but with persistent volumes, data stays safe across pod restarts.

Execution Sample

Kubernetes

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: app
    image: busybox
    volumeMounts:
    - mountPath: /data
      name: storage
  volumes:
  - name: storage
    persistentVolumeClaim:
      claimName: pvc-example

This Kubernetes pod spec mounts a persistent volume claim to /data inside the container, ensuring data persists beyond pod lifecycle.

Process Table

Step	Pod State	Storage Type	Data Status	Action
1	Pod starts	Ephemeral	Empty	Pod writes data to local storage
2	Pod running	Ephemeral	Data present	Application uses data
3	Pod crashes	Ephemeral	Data lost	Pod restarts, ephemeral storage cleared
4	Pod restarts	Ephemeral	Empty	Application starts fresh, data lost
5	Pod starts	Persistent Volume	Empty	Pod mounts persistent volume
6	Pod running	Persistent Volume	Data present	Application writes data to PV
7	Pod crashes	Persistent Volume	Data preserved	Pod restarts, PV still attached
8	Pod restarts	Persistent Volume	Data present	Application resumes with data intact

💡 Execution stops after pod restarts with persistent volume and data remains intact.

Status Tracker

Variable	Start	After Step 2	After Step 4	After Step 6	After Step 8
Pod State	Not running	Running	Restarted	Running	Restarted
Storage Type	None	Ephemeral	Ephemeral	Persistent Volume	Persistent Volume
Data Status	None	Present	Lost	Present	Present

Key Moments - 3 Insights

Why does data disappear after pod restart without persistent storage?

Because ephemeral storage is tied to the pod lifecycle, when the pod restarts, its local storage is wiped, as shown in execution_table steps 3 and 4.

How does persistent storage keep data safe across pod restarts?

Persistent Volumes exist independently of pods, so data written to them remains even if pods restart, as seen in execution_table steps 7 and 8.

What happens if a pod uses persistent storage but the volume is not mounted correctly?

The pod will not have access to the stored data, effectively behaving like ephemeral storage, losing data on restart. This is implied by the need to mount the volume in the pod spec.

Visual Quiz - 3 Questions

Look at the execution table, at which step does the pod lose its data when using ephemeral storage?

A Step 7

B Step 5

C Step 3

D Step 8

💡 Hint

Check the 'Data Status' column for ephemeral storage rows in execution_table.

According to variable_tracker, what is the 'Data Status' after step 6 when using persistent storage?

A Lost

B Present

C Empty

D None

💡 Hint

Look at the 'Data Status' row under 'After Step 6' in variable_tracker.

If the pod never mounts a persistent volume, how would the execution_table change after pod restart?

A Data would be lost after restart

B Data would remain present after restart

C Pod would fail to start

D Pod would use persistent storage automatically

💡 Hint

Refer to steps 3 and 4 in execution_table showing ephemeral storage behavior.

Concept Snapshot

Kubernetes pods use ephemeral storage by default, which is lost on pod restart.
Persistent Volumes (PV) provide storage that outlives pods.
Pods mount Persistent Volume Claims (PVC) to use PVs.
Data on PV remains after pod crashes or restarts.
Use PVs for databases, logs, or any data needing persistence.

Full Transcript

In Kubernetes, pods by default use ephemeral storage that disappears when the pod restarts. This means any data saved inside the pod is lost if the pod crashes or is deleted. To keep data safe, Kubernetes uses Persistent Volumes (PV) which exist independently of pods. Pods connect to these volumes using Persistent Volume Claims (PVC). When a pod writes data to a PV, that data stays even if the pod restarts. This is important for applications like databases that need to keep data safe. The execution table shows how data is lost with ephemeral storage but preserved with persistent storage. The variable tracker shows pod state, storage type, and data status changes step by step. Understanding this helps avoid data loss in Kubernetes applications.

Practice

1. Why is persistent storage important in Kubernetes?

easy

A. It speeds up container startup time

B. It manages network traffic between pods

C. It automatically scales the number of pods

D. It keeps data safe even if containers stop or restart

Solution

1. Step 1: Understand container lifecycle

   Containers can stop or restart anytime, losing any data stored inside them.

2. Step 2: Role of persistent storage

   Persistent storage keeps data safe beyond container life, so data is not lost.

3. Final Answer:

   It keeps data safe even if containers stop or restart -> Option D

4. Quick Check:

   Persistent storage = data safety beyond containers [OK]

Hint: Persistent storage saves data beyond container life [OK]

Common Mistakes:

• Thinking persistent storage speeds up containers
• Confusing storage with network management
• Assuming storage auto-scales pods

2. Which of the following is the correct way to request persistent storage in Kubernetes?

easy

A. kubectl get storageclass

B. kubectl create pod --storage

C. kubectl apply -f persistentvolumeclaim.yaml

D. kubectl delete pvc

Solution

1. Step 1: Identify how to request storage

   PersistentVolumeClaim (PVC) is used to request storage in Kubernetes.

2. Step 2: Correct command to apply PVC

   Using kubectl apply -f persistentvolumeclaim.yaml applies the PVC configuration.

3. Final Answer:

   kubectl apply -f persistentvolumeclaim.yaml -> Option C

4. Quick Check:

   Request storage with PVC YAML and apply [OK]

Hint: Use kubectl apply with PVC YAML to request storage [OK]

Common Mistakes:

• Using pod creation command to request storage
• Confusing storageclass listing with requesting storage
• Deleting PVC instead of creating it

3. Given this PersistentVolumeClaim YAML snippet:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi

What does ReadWriteOnce mean?

medium

A. The volume can be mounted as read-write by only one pod at a time

B. The volume is automatically deleted when pod stops

C. The volume is read-only for all pods

D. The volume can be mounted as read-write by many pods simultaneously

Solution

1. Step 1: Understand accessModes in PVC

   AccessModes define how many pods can mount the volume and with what permissions.

2. Step 2: Meaning of ReadWriteOnce

   ReadWriteOnce means only one pod can mount the volume as read-write at a time.

3. Final Answer:

   The volume can be mounted as read-write by only one pod at a time -> Option A

4. Quick Check:

   ReadWriteOnce = single pod read-write mount [OK]

Hint: ReadWriteOnce means single pod read-write access [OK]

Common Mistakes:

• Thinking ReadWriteOnce allows multiple pods
• Confusing read-only with ReadWriteOnce
• Assuming volume auto-deletes with pod

4. You created a PersistentVolumeClaim but your pod fails to mount the volume with error "volume not found". What is the most likely cause?

medium

A. The PersistentVolumeClaim name does not match the volume name in the pod spec

B. The pod spec is missing the container image

C. The PersistentVolumeClaim requested storage size is too small

D. The pod is missing resource limits

Solution

1. Step 1: Check volume mount configuration

   The pod must reference the PVC by the exact name to mount the volume.

2. Step 2: Identify cause of "volume not found" error

   If names don't match, Kubernetes cannot find the volume to mount.

3. Final Answer:

   The PersistentVolumeClaim name does not match the volume name in the pod spec -> Option A

4. Quick Check:

   Volume mount fails if PVC name mismatches [OK]

Hint: Match PVC name exactly in pod volume spec [OK]

Common Mistakes:

• Ignoring volume name mismatch
• Blaming container image for volume errors
• Assuming storage size causes mount failure

5. You want two pods to share the same persistent storage volume with read-write access at the same time. Which access mode should you specify in your PersistentVolumeClaim?

hard

A. ReadWriteOnce

B. ReadWriteMany

C. ReadOnlyMany

D. WriteOnce

Solution

1. Step 1: Understand access modes for sharing

   ReadWriteMany allows multiple pods to mount the volume as read-write simultaneously.

2. Step 2: Choose correct access mode for sharing

   Since two pods need read-write access at the same time, ReadWriteMany is required.

3. Final Answer:

   ReadWriteMany -> Option B

4. Quick Check:

   Multiple pods read-write = ReadWriteMany [OK]

Hint: Use ReadWriteMany for shared read-write access [OK]

Common Mistakes:

• Using ReadWriteOnce which allows only one pod
• Confusing ReadOnlyMany with read-write access
• Selecting non-existent WriteOnce mode