Volumes vs Persistent Volumes in Kubernetes - Visual Side-by-Side Comparison

Process Flow - Volumes vs Persistent Volumes

Pod starts

↓

Volume attached

↓

Data stored temporarily

↓

Pod stops -> Volume lost

↓

Persistent Volume created

↓

Pod claims Persistent Volume

↓

Data stored persistently

↓

Pod stops -> Data remains intact

Shows how normal Volumes exist only during pod life, while Persistent Volumes keep data beyond pod life.

Execution Sample

Kubernetes

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  volumes:
  - name: temp-volume
    emptyDir: {}
  containers:
  - name: app
    image: busybox
    volumeMounts:
    - mountPath: /data
      name: temp-volume

Defines a pod with a temporary volume (emptyDir) that lasts only while the pod runs.

Process Table

Step	Action	Volume Type	Data Persistence	Result
1	Pod starts	emptyDir Volume	Data stored temporarily	Volume created and mounted to pod
2	Write data inside pod at /data	emptyDir Volume	Data available during pod life	Data written successfully
3	Pod stops	emptyDir Volume	Data lost after pod stops	Volume deleted, data lost
4	PersistentVolume created by admin	Persistent Volume	Data stored persistently	Volume ready for claim
5	Pod claims PersistentVolume via PersistentVolumeClaim	Persistent Volume	Data persists beyond pod life	Volume mounted to pod
6	Write data inside pod at mounted path	Persistent Volume	Data saved persistently	Data written successfully
7	Pod stops	Persistent Volume	Data remains intact	Volume still exists with data

💡 Pod lifecycle ends; emptyDir volume data lost, Persistent Volume data remains.

Status Tracker

Variable	Start	After Step 2	After Step 3	After Step 6	After Step 7
emptyDir Volume Data	none	data present	lost (none)	n/a	n/a
Persistent Volume Data	none	n/a	n/a	data present	data present

Key Moments - 3 Insights

Why does data in emptyDir volume disappear after pod stops?

Because emptyDir volumes exist only during pod life, as shown in execution_table step 3 where pod stops and data is lost.

How does Persistent Volume keep data after pod stops?

Persistent Volumes are independent resources that exist beyond pod lifecycle, shown in steps 4-7 where data remains after pod stops.

Can multiple pods share the same Persistent Volume?

Yes, Persistent Volumes can be shared if configured, unlike emptyDir which is pod-specific. This is implied by Persistent Volume being separate from pod lifecycle.

Visual Quiz - 3 Questions

Look at the execution table, what happens to data in emptyDir volume at step 3?

A Data is lost because pod stops

B Data is saved permanently

C Data is copied to Persistent Volume

D Data is backed up automatically

💡 Hint

Check execution_table row for step 3 under 'Result' and 'Data Persistence'

At which step does the pod claim a Persistent Volume?

A Step 2

B Step 5

C Step 1

D Step 7

💡 Hint

Look at execution_table 'Action' column for pod claiming Persistent Volume

If the pod using emptyDir volume restarts, what happens to the data?

A Data is moved to Persistent Volume automatically

B Data remains intact after restart

C Data is lost and volume is recreated

D Pod cannot restart with emptyDir volume

💡 Hint

Refer to variable_tracker for emptyDir Volume Data after pod stops (step 3)

Concept Snapshot

Volumes in Kubernetes are temporary storage tied to pod life (e.g., emptyDir).
Persistent Volumes are independent storage resources that keep data beyond pod lifecycle.
Pods use PersistentVolumeClaims to access Persistent Volumes.
emptyDir data is lost when pod stops; Persistent Volume data remains.
Use Persistent Volumes for important data needing durability.

Full Transcript

This visual execution compares Kubernetes Volumes and Persistent Volumes. When a pod starts, it can use a Volume like emptyDir which stores data temporarily. Data written to emptyDir is lost when the pod stops, as shown in step 3 of the execution table. In contrast, Persistent Volumes are created separately and exist beyond pod life. Pods claim Persistent Volumes via PersistentVolumeClaims, mount them, and write data that persists even after the pod stops, demonstrated in steps 4 to 7. The variable tracker shows emptyDir data disappears after pod stops, while Persistent Volume data remains. Key moments clarify why emptyDir data is lost and how Persistent Volumes provide durable storage. The quiz tests understanding of these lifecycle differences and data persistence behaviors.

Practice

1. What is the main difference between a Volume and a Persistent Volume in Kubernetes?

easy

A. Volumes are temporary and tied to pod lifecycle; Persistent Volumes are durable and independent.

B. Volumes are used only for databases; Persistent Volumes are for logs.

C. Volumes require manual creation; Persistent Volumes are created automatically.

D. Volumes can be shared across clusters; Persistent Volumes cannot.

Solution

1. Step 1: Understand Volume lifecycle

   Volumes exist only as long as the pod runs, so they are temporary storage tied to pod lifecycle.

2. Step 2: Understand Persistent Volume purpose

   Persistent Volumes exist independently of pods and provide durable storage that remains after pods are deleted.

3. Final Answer:

   Volumes are temporary and tied to pod lifecycle; Persistent Volumes are durable and independent. -> Option A

4. Quick Check:

   Volume lifecycle = temporary, Persistent Volume = durable [OK]

Hint: Remember: Volumes die with pods; Persistent Volumes live beyond pods [OK]

Common Mistakes:

• Thinking Volumes are durable storage
• Confusing Persistent Volumes as pod-specific
• Assuming Volumes can be shared across clusters

2. Which of the following is the correct way to declare a Persistent Volume Claim (PVC) in a pod spec?

easy

A. "volumes:\n - name: mypvc\n persistentVolumeClaim:\n claimName: myclaim"

B. "volumes:\n - name: mypvc\n emptyDir: {}"

C. "volumes:\n - name: mypvc\n hostPath:\n path: /data"

D. "volumes:\n - name: mypvc\n configMap:\n name: myconfig"

Solution

1. Step 1: Identify PVC syntax in pod spec

   Persistent Volume Claims are referenced under volumes with persistentVolumeClaim.claimName.

2. Step 2: Check other volume types

   emptyDir is temporary storage, hostPath mounts host directory, configMap mounts config data, none are PVCs.

3. Final Answer:

   volumes: - name: mypvc persistentVolumeClaim: claimName: myclaim -> Option A

4. Quick Check:

   PVC uses persistentVolumeClaim.claimName [OK]

Hint: PVCs use persistentVolumeClaim with claimName in volumes [OK]

Common Mistakes:

• Using emptyDir or hostPath instead of persistentVolumeClaim
• Missing claimName field
• Confusing configMap with PVC

3. Given this pod spec snippet, what type of storage is being used?

volumes:
  - name: temp-storage
    emptyDir: {}

medium

A. Persistent Volume storage

B. HostPath volume storage

C. Temporary Volume storage tied to pod lifecycle

D. Persistent Volume Claim storage

Solution

1. Step 1: Identify volume type from spec

   The volume uses emptyDir, which is a temporary directory created when the pod starts.

2. Step 2: Understand emptyDir lifecycle

   emptyDir storage is deleted when the pod is removed, so it is temporary and tied to pod lifecycle.

3. Final Answer:

   Temporary Volume storage tied to pod lifecycle -> Option C

4. Quick Check:

   emptyDir = temporary pod storage [OK]

Hint: emptyDir means temporary storage deleted with pod [OK]

Common Mistakes:

• Assuming emptyDir is persistent storage
• Confusing emptyDir with hostPath
• Thinking emptyDir uses Persistent Volume Claims

4. You created a pod with a volume referencing a Persistent Volume Claim, but the pod fails to start with an error about volume not found. What is the most likely cause?

medium

A. The Persistent Volume is deleted automatically when pod is deleted.

B. The pod spec uses emptyDir instead of persistentVolumeClaim.

C. The pod is missing a container image.

D. The Persistent Volume Claim does not exist or is not bound to a Persistent Volume.

Solution

1. Step 1: Analyze error cause

   If the pod cannot find the volume from PVC, likely the PVC does not exist or is not bound to any Persistent Volume.

2. Step 2: Check other options

   Using emptyDir would not cause volume not found error; missing container image causes different error; Persistent Volumes are independent of pods.

3. Final Answer:

   The Persistent Volume Claim does not exist or is not bound to a Persistent Volume. -> Option D

4. Quick Check:

   Volume not found = missing or unbound PVC [OK]

Hint: Check PVC existence and binding if volume not found error occurs [OK]

Common Mistakes:

• Assuming emptyDir causes volume not found
• Ignoring PVC binding status
• Confusing pod image errors with volume errors

5. You want to ensure data stored by your pod remains even if the pod is deleted and recreated. Which combination should you use?

hard

A. Use a Volume with emptyDir in the pod spec.

B. Use a Persistent Volume with a Persistent Volume Claim referenced in the pod spec.

C. Use a hostPath volume pointing to a temporary directory.

D. Use a ConfigMap volume to store data files.

Solution

1. Step 1: Identify storage durability requirement

   Data must persist beyond pod lifecycle, so temporary volumes like emptyDir or hostPath to temp dirs won't work.

2. Step 2: Choose correct storage type

   Persistent Volumes with PVCs provide durable storage independent of pods, ensuring data remains after pod deletion.

3. Final Answer:

   Use a Persistent Volume with a Persistent Volume Claim referenced in the pod spec. -> Option B

4. Quick Check:

   Persistent Volume + PVC = durable storage [OK]

Hint: For durable data, always use Persistent Volume with PVC [OK]

Common Mistakes:

• Using emptyDir for persistent data
• Using hostPath to temporary directories
• Confusing ConfigMap with storage for data