PersistentVolume (PV) definition in Kubernetes - Step-by-Step Execution

Process Flow - PersistentVolume (PV) definition

Write PV YAML file

↓

kubectl apply -f pv.yaml

↓

Kubernetes API Server receives PV spec

↓

PV object created in cluster

↓

PV available for claim by Pods

↓

Pod uses PersistentVolumeClaim to bind PV

The flow shows how a PersistentVolume YAML is created, applied to the cluster, and then made available for Pods to use via claims.

Execution Sample

Kubernetes

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-example
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: /mnt/data

This YAML defines a PersistentVolume named 'pv-example' with 5Gi storage and ReadWriteOnce access mode using hostPath.

Process Table

Step	Action	Input/Command	Result/State Change
1	Write PV YAML file	pv.yaml with PV spec	File created with PV definition
2	Apply PV to cluster	kubectl apply -f pv.yaml	PV object 'pv-example' created in Kubernetes
3	Kubernetes API Server processes PV	PV spec received	PV stored and marked as Available
4	PV ready for claim	PV status Available	Pod can bind via PersistentVolumeClaim
5	Pod binds PV	Pod PVC requests PV	PV bound to Pod's PVC

💡 PV is created and available for Pods to claim and use storage.

Status Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	Final
PV Object	None	Created with spec	Stored as Available	Ready for claim	Bound to Pod PVC

Key Moments - 2 Insights

Why does the PV status change to 'Available' after creation?

After applying the YAML (see execution_table step 3), Kubernetes marks the PV as 'Available' to show it is ready to be claimed by a PersistentVolumeClaim.

What happens if no Pod claims the PV?

The PV remains in 'Available' state (execution_table step 4) until a Pod's PersistentVolumeClaim binds to it or it is deleted.

Visual Quiz - 3 Questions

Look at the execution table, at which step is the PV object created in Kubernetes?

A Step 3

B Step 1

C Step 2

D Step 4

💡 Hint

Check the 'Result/State Change' column for when the PV object is created.

According to the variable tracker, what is the PV status after Step 3?

A None

B Stored as Available

C Created with spec

D Bound to Pod PVC

💡 Hint

Look at the 'After Step 3' column for the PV Object variable.

If the Pod never claims the PV, what will be the final state of the PV according to the execution table?

A Available

B Deleted

C Bound to Pod PVC

D Pending

💡 Hint

Refer to the key moments and execution_table step 4 about PV availability.

Concept Snapshot

PersistentVolume (PV) is a cluster resource representing storage.
Define PV in YAML with capacity, accessModes, and storage details.
Apply with 'kubectl apply -f pv.yaml' to create PV object.
PV status 'Available' means ready for claim.
Pods use PersistentVolumeClaim to bind and use PV storage.

Full Transcript

This visual execution shows how a PersistentVolume (PV) is defined and created in Kubernetes. First, a YAML file is written with the PV specification including storage size and access mode. Then, the YAML is applied using kubectl, which creates the PV object in the cluster. The Kubernetes API server processes this and marks the PV as Available, meaning it is ready to be claimed. Finally, a Pod can bind to this PV by using a PersistentVolumeClaim. The variable tracker shows the PV object's state changing from none to created, available, and finally bound. Key moments clarify why PV status changes and what happens if no Pod claims it. The quiz tests understanding of creation steps, PV status, and final states if unclaimed.

Practice

1. What is the main purpose of a PersistentVolume (PV) in Kubernetes?

easy

A. To manage container images

B. To define network policies for pods

C. To schedule pods on specific nodes

D. To provide storage that can persist beyond the lifecycle of a pod

Solution

1. Step 1: Understand the role of PersistentVolume

   A PersistentVolume provides storage resources independent of pod lifecycle.

2. Step 2: Compare with other options

   Network policies, pod scheduling, and image management are unrelated to PV.

3. Final Answer:

   To provide storage that can persist beyond the lifecycle of a pod -> Option D

4. Quick Check:

   PV = persistent storage [OK]

Hint: PV stores data beyond pod life, not network or scheduling [OK]

Common Mistakes:

• Confusing PV with pod scheduling
• Thinking PV manages network policies
• Assuming PV handles container images

2. Which of the following is the correct minimal YAML snippet to define a PersistentVolume with 5Gi storage and ReadWriteOnce access mode?

easy

A. apiVersion: v1\nkind: PersistentVolume\nmetadata:\n name: pv-example\nspec:\n capacity:\n storage: 5GB\n accessModes:\n - ReadOnlyMany\n hostPath:\n path: /mnt/data

B. apiVersion: v1\nkind: PersistentVolume\nmetadata:\n name: pv-example\nspec:\n capacity:\n storage: 5Gi\n accessModes:\n - ReadWriteOnce\n hostPath:\n path: /mnt/data

C. apiVersion: v1\nkind: PersistentVolume\nmetadata:\n name: pv-example\nspec:\n size: 5Gi\n accessModes:\n - ReadWriteMany\n hostPath:\n path: /mnt/data

D. apiVersion: v1\nkind: PersistentVolumeClaim\nmetadata:\n name: pvc-example\nspec:\n storage: 5Gi\n accessModes:\n - ReadWriteOnce

Solution

1. Step 1: Check correct kind and apiVersion

   PersistentVolume uses kind: PersistentVolume and apiVersion: v1.

2. Step 2: Validate capacity and accessModes syntax

   Capacity must be under spec.capacity.storage with unit Gi, and accessModes is a list with ReadWriteOnce.

3. Final Answer:

   YAML with capacity 5Gi, accessModes ReadWriteOnce, kind PersistentVolume -> Option B

4. Quick Check:

   Correct YAML keys and values = apiVersion: v1\nkind: PersistentVolume\nmetadata:\n name: pv-example\nspec:\n capacity:\n storage: 5Gi\n accessModes:\n - ReadWriteOnce\n hostPath:\n path: /mnt/data [OK]

Hint: PV uses spec.capacity.storage with units like Gi, not size or GB [OK]

Common Mistakes:

• Using PersistentVolumeClaim instead of PersistentVolume
• Wrong key 'size' instead of 'capacity.storage'
• Incorrect storage unit like GB instead of Gi
• Wrong access mode or misspelled keys

3. Given this PersistentVolume YAML snippet, what is the reclaim policy of the PV?

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-sample
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: /mnt/data

medium

A. Delete the volume after release

B. Recycle the volume automatically

C. Retain the volume after release

D. No reclaim policy set

Solution

1. Step 1: Locate the reclaim policy field

   The field persistentVolumeReclaimPolicy is set to Retain in the spec.

2. Step 2: Understand reclaim policy meaning

   Retain means the volume is kept after the claim is released, not deleted or recycled.

3. Final Answer:

   Retain the volume after release -> Option C

4. Quick Check:

   persistentVolumeReclaimPolicy = Retain [OK]

Hint: Look for persistentVolumeReclaimPolicy field value [OK]

Common Mistakes:

• Confusing Retain with Delete or Recycle
• Ignoring the reclaim policy field
• Assuming default policy without checking

4. You defined this PersistentVolume YAML but get an error when applying it:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-error
spec:
  capacity:
    storage: 20Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Delete
  hostPath:
    path: /mnt/data
  storageClassName: fast

What is the likely cause of the error?

medium

A. hostPath volumes cannot have storageClassName set

B. accessModes value ReadWriteOnce is invalid

C. Missing volumeMode field

D. persistentVolumeReclaimPolicy Delete is not allowed

Solution

1. Step 1: Check hostPath volume restrictions

   hostPath volumes do not support storageClassName because they are local paths.

2. Step 2: Validate other fields

   accessModes and reclaim policy values are valid; volumeMode is optional.

3. Final Answer:

   hostPath volumes cannot have storageClassName set -> Option A

4. Quick Check:

   hostPath + storageClassName = error [OK]

Hint: hostPath volumes must not set storageClassName [OK]

Common Mistakes:

• Assuming volumeMode is mandatory
• Thinking accessModes ReadWriteOnce is invalid
• Believing Delete reclaim policy is disallowed

5. You want to create a PersistentVolume that allows multiple pods to read and write simultaneously and automatically deletes the volume when released. Which YAML snippet correctly defines these requirements?

hard

A. apiVersion: v1\nkind: PersistentVolume\nmetadata:\n name: pv-multi\nspec:\n capacity:\n storage: 15Gi\n accessModes:\n - ReadWriteMany\n persistentVolumeReclaimPolicy: Delete\n nfs:\n path: /exports/data\n server: 10.0.0.1

B. apiVersion: v1\nkind: PersistentVolume\nmetadata:\n name: pv-single\nspec:\n capacity:\n storage: 15Gi\n accessModes:\n - ReadWriteOnce\n persistentVolumeReclaimPolicy: Retain\n hostPath:\n path: /mnt/data

C. apiVersion: v1\nkind: PersistentVolume\nmetadata:\n name: pv-multi\nspec:\n capacity:\n storage: 15Gi\n accessModes:\n - ReadOnlyMany\n persistentVolumeReclaimPolicy: Delete\n nfs:\n path: /exports/data\n server: 10.0.0.1

D. apiVersion: v1\nkind: PersistentVolume\nmetadata:\n name: pv-multi\nspec:\n capacity:\n storage: 15Gi\n accessModes:\n - ReadWriteMany\n persistentVolumeReclaimPolicy: Retain\n nfs:\n path: /exports/data\n server: 10.0.0.1

Solution

1. Step 1: Identify access mode for multiple pods read/write

   ReadWriteMany allows multiple pods to read and write simultaneously.

2. Step 2: Check reclaim policy for automatic deletion

   persistentVolumeReclaimPolicy: Delete deletes the volume after release.

3. Step 3: Confirm storage type supports ReadWriteMany

   NFS supports ReadWriteMany; hostPath does not.

4. Final Answer:

   YAML with ReadWriteMany, Delete reclaim policy, and NFS volume -> Option A

5. Quick Check:

   ReadWriteMany + Delete + NFS = apiVersion: v1\nkind: PersistentVolume\nmetadata:\n name: pv-multi\nspec:\n capacity:\n storage: 15Gi\n accessModes:\n - ReadWriteMany\n persistentVolumeReclaimPolicy: Delete\n nfs:\n path: /exports/data\n server: 10.0.0.1 [OK]

Hint: Use ReadWriteMany + Delete + NFS for multi-pod writable PV [OK]

Common Mistakes:

• Using hostPath for multi-pod access
• Choosing ReadWriteOnce instead of ReadWriteMany
• Setting reclaim policy to Retain instead of Delete