PersistentVolumeClaim (PVC) definition in Kubernetes - Step-by-Step Execution

Process Flow - PersistentVolumeClaim (PVC) definition

Write PVC YAML

↓

kubectl apply PVC

↓

Kubernetes API Server receives

↓

PVC stored in etcd

↓

PVC status: Pending

↓

Controller finds matching PV

↓

Bind PV to PVC

↓

PVC status: Bound

↓

Pod uses PVC to mount storage

This flow shows how a PVC is defined, applied, matched to a PV, and then bound for use by a pod.

Execution Sample

Kubernetes

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

This YAML defines a PVC requesting 1Gi storage with ReadWriteOnce access mode.

Process Table

Step	Action	Evaluation	Result
1	Write PVC YAML file	YAML valid	PVC definition ready
2	Run 'kubectl apply -f pvc.yaml'	kubectl sends request	PVC object created in cluster
3	API Server stores PVC	PVC stored in etcd	PVC status is Pending
4	Controller checks for matching PV	Find PV with >=1Gi and ReadWriteOnce	PV found and bound to PVC
5	PVC status updated	PVC status changes to Bound	PVC ready for pod use
6	Pod mounts PVC volume	Pod uses PVC name	Pod has persistent storage mounted
7	End	PVC bound and usable	Process complete

💡 PVC is bound to a matching PV and ready for pod usage

Status Tracker

Variable	Start	After Step 3	After Step 5	Final
PVC.status.phase	None	Pending	Bound	Bound
PVC.spec.resources.requests.storage	None	1Gi	1Gi	1Gi
PVC.spec.accessModes[0]	None	ReadWriteOnce	ReadWriteOnce	ReadWriteOnce

Key Moments - 3 Insights

Why does the PVC status start as Pending?

At step 3 in the execution_table, the PVC is created but not yet matched to a PersistentVolume, so its status is Pending until a suitable PV is found and bound.

What does 'Bound' status mean for a PVC?

As shown in step 5, 'Bound' means the PVC has been successfully matched and linked to a PersistentVolume, making the storage ready for use by pods.

Can a pod use a PVC before it is Bound?

No, according to step 6, the pod can only mount the PVC after its status is Bound, ensuring the storage is allocated and available.

Visual Quiz - 3 Questions

Look at the execution_table, what is the PVC status after step 3?

A Released

B Bound

C Pending

D Lost

💡 Hint

Check the 'Result' column at step 3 in the execution_table.

At which step does the PVC become ready for pod use?

A Step 5

B Step 3

C Step 2

D Step 1

💡 Hint

Look for when PVC status changes to Bound in the execution_table.

If the requested storage was increased to 5Gi, what would change in the execution_table?

A Step 6 would be skipped

B Step 4 would look for PV with >=5Gi

C Step 3 PVC status would be Bound immediately

D No changes at all

💡 Hint

Refer to step 4 where the controller finds a matching PV based on requested storage.

Concept Snapshot

PersistentVolumeClaim (PVC) is a request for storage in Kubernetes.
Define PVC in YAML with accessModes and storage size.
Apply with kubectl to create PVC object.
PVC status starts Pending until matched to a PersistentVolume (PV).
Once Bound, pods can mount the PVC for persistent storage.

Full Transcript

This visual execution traces the lifecycle of a PersistentVolumeClaim (PVC) in Kubernetes. First, a PVC YAML is written specifying storage size and access mode. When applied with kubectl, the PVC object is created and stored in the cluster with status Pending. The controller then searches for a matching PersistentVolume (PV) that meets the requested size and access mode. Once found, the PV is bound to the PVC, updating its status to Bound. Finally, pods can mount the PVC to use the persistent storage. Key moments include understanding the Pending and Bound statuses and knowing that pods can only use PVCs after they are Bound.

Practice

1. What is the main purpose of a PersistentVolumeClaim (PVC) in Kubernetes?

easy

A. To configure network policies

B. To define a container image for a pod

C. To schedule pods on specific nodes

D. To request storage resources from the cluster

Solution

1. Step 1: Understand PVC role

   A PVC is used to request storage resources in Kubernetes, separating storage use from storage details.

2. Step 2: Compare options

   Options A, B, and D relate to other Kubernetes features, not storage requests.

3. Final Answer:

   To request storage resources from the cluster -> Option D

4. Quick Check:

   PVC = Storage request [OK]

Hint: PVC always requests storage, not images or network [OK]

Common Mistakes:

• Confusing PVC with Pod or Deployment definitions
• Thinking PVC schedules pods
• Mixing PVC with network policies

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

easy

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

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

C. apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: my-pvc
spec:
accessModes:
- ReadWriteMany
resources:
limits:
storage: 5Gi

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

Solution

1. Step 1: Check accessModes and storage request

   apiVersion: v1 kind: PersistentVolumeClaim metadata: name: my-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 5Gi correctly uses ReadWriteOnce and requests 5Gi storage under resources.requests.

2. Step 2: Identify errors in other options

   apiVersion: v1 kind: PersistentVolumeClaim metadata: name: my-pvc spec: accessModes: - ReadOnlyMany resources: requests: storage: 5Gi uses ReadOnlyMany (not requested). apiVersion: v1 kind: PersistentVolumeClaim metadata: name: my-pvc spec: accessModes: - ReadWriteMany resources: limits: storage: 5Gi uses limits instead of requests. apiVersion: v1 kind: PersistentVolumeClaim metadata: name: my-pvc spec: accessModes: - ReadWriteOnce resources: requests: cpu: 5Gi incorrectly requests cpu instead of storage.

3. Final Answer:

   Correct minimal PVC YAML with 5Gi and ReadWriteOnce -> Option B

4. Quick Check:

   accessModes + storage request = apiVersion: v1 kind: PersistentVolumeClaim metadata: name: my-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 5Gi [OK]

Hint: Use resources.requests.storage for size, accessModes for access [OK]

Common Mistakes:

• Using limits instead of requests for storage
• Wrong accessModes value
• Requesting cpu instead of storage

3. Given this PVC YAML snippet, what will be the requested storage size and access mode?

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 10Gi
  storageClassName: fast-storage

medium

A. 10Gi storage with ReadWriteMany access

B. 10Gi storage with ReadWriteOnce access

C. 5Gi storage with ReadWriteMany access

D. 10Gi storage with ReadOnlyMany access

Solution

1. Step 1: Read storage size

   The YAML requests 10Gi storage under resources.requests.storage.

2. Step 2: Read access mode

   Access mode is ReadWriteMany as specified under accessModes.

3. Final Answer:

   10Gi storage with ReadWriteMany access -> Option A

4. Quick Check:

   storage=10Gi, access=ReadWriteMany [OK]

Hint: Check resources.requests.storage and accessModes list [OK]

Common Mistakes:

• Confusing ReadWriteOnce with ReadWriteMany
• Misreading storage size
• Ignoring storageClassName as it doesn't affect size or access

4. Identify the error in this PVC YAML snippet:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: test-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 2GB

medium

A. metadata name is missing

B. accessModes should be ReadOnlyMany

C. storage size unit should be Gi, not GB

D. apiVersion should be apps/v1

Solution

1. Step 1: Check storage size unit

   Kubernetes expects storage size units like Gi, Mi, not GB. '2GB' is invalid.

2. Step 2: Verify other fields

   accessModes and metadata name are correct. apiVersion for PVC is v1, not apps/v1.

3. Final Answer:

   storage size unit should be Gi, not GB -> Option C

4. Quick Check:

   Use Gi for storage size units [OK]

Hint: Use Gi, Mi units for storage size, not GB [OK]

Common Mistakes:

• Using GB instead of Gi for storage size
• Wrong apiVersion for PVC
• Changing accessModes unnecessarily

5. You want to create a PVC that requests 20Gi storage with ReadWriteOnce access and uses a storage class named "premium-ssd". Which YAML snippet correctly defines this PVC?

hard

A. apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: premium-pvc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 20Gi
storageClassName: premium-ssd

B. apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: premium-pvc
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 20Gi
storageClassName: premium-ssd

C. apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: premium-pvc
spec:
accessModes:
- ReadWriteOnce
resources:
limits:
storage: 20Gi
storageClassName: premium-ssd

D. apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: premium-pvc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 20GB
storageClassName: premium-ssd

Solution

1. Step 1: Verify accessModes and storage size

   apiVersion: v1 kind: PersistentVolumeClaim metadata: name: premium-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 20Gi storageClassName: premium-ssd uses ReadWriteOnce and requests 20Gi storage correctly.

2. Step 2: Check storageClassName and units

   apiVersion: v1 kind: PersistentVolumeClaim metadata: name: premium-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 20Gi storageClassName: premium-ssd correctly sets storageClassName to premium-ssd and uses Gi units. Other options have wrong accessModes, use limits instead of requests, or wrong units (GB).

3. Final Answer:

   Correct PVC with 20Gi, ReadWriteOnce, and premium-ssd storage class -> Option A

4. Quick Check:

   accessModes=ReadWriteOnce + requests.storage=20Gi + storageClassName= premium-ssd [OK]

Hint: Use requests.storage with Gi units and correct accessModes [OK]

Common Mistakes:

• Using limits instead of requests for storage
• Wrong accessModes value
• Using GB instead of Gi for storage size