Storage classes for dynamic provisioning in Kubernetes - Step-by-Step Execution

Process Flow - Storage classes for dynamic provisioning

User creates PVC

↓

PVC requests storage

↓

Kubernetes checks StorageClass

↓

StorageClass triggers dynamic provisioning

↓

Provisioner creates PersistentVolume

↓

PV bound to PVC

↓

Pod uses the storage

This flow shows how a PersistentVolumeClaim (PVC) triggers dynamic storage provisioning via a StorageClass, which creates a PersistentVolume (PV) bound to the PVC for pod use.

Execution Sample

Kubernetes

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mypvc
spec:
  storageClassName: fast
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi

This YAML defines a PVC requesting 5Gi storage with the 'fast' StorageClass for dynamic provisioning.

Process Table

Step	Action	Resource	Result	Notes
1	Create PVC	PersistentVolumeClaim 'mypvc'	PVC created and pending	PVC waits for storage provisioning
2	Kubernetes reads PVC	PVC 'mypvc'	Identifies StorageClass 'fast'	StorageClass defines provisioner and parameters
3	Trigger dynamic provisioning	StorageClass 'fast'	Provisioner starts creating PV	Provisioner may be cloud or local driver
4	Provision PV	PersistentVolume	PV created with 5Gi storage	PV matches PVC requirements
5	Bind PV to PVC	PV and PVC	PVC bound to PV	PVC status changes to Bound
6	Pod uses PVC	Pod volume mount	Pod can read/write storage	Storage ready for application use
7	End	-	Dynamic provisioning complete	Storage allocated dynamically

💡 PVC bound to dynamically provisioned PV, ready for pod use

Status Tracker

Resource	Initial State	After Step 2	After Step 4	After Step 5	Final State
PersistentVolumeClaim 'mypvc'	Not created	Created, Pending	Pending	Bound to PV	Bound
PersistentVolume	Not created	Not created	Created with 5Gi	Bound to PVC	Bound
StorageClass 'fast'	Exists	Used for provisioning	Provisioning in progress	Provisioning complete	Provisioned

Key Moments - 3 Insights

Why does the PVC stay in Pending state initially?

The PVC stays Pending because Kubernetes waits for the StorageClass provisioner to create a matching PersistentVolume dynamically, as shown in steps 1 and 2 of the execution_table.

How does Kubernetes know which provisioner to use?

Kubernetes reads the StorageClass specified in the PVC (step 2) which contains the provisioner information, triggering dynamic provisioning (step 3).

What happens if no StorageClass is specified in the PVC?

If no StorageClass is specified, dynamic provisioning does not occur automatically, and the PVC remains Pending until a matching PV exists or is manually created.

Visual Quiz - 3 Questions

Look at the execution_table, at which step is the PersistentVolume created?

A Step 4

B Step 3

C Step 5

D Step 2

💡 Hint

Check the 'Resource' and 'Result' columns in execution_table row for step 4.

According to variable_tracker, what is the state of the PVC after step 5?

A Pending

B Bound to PV

C Not created

D Deleted

💡 Hint

Look at the 'PersistentVolumeClaim' row under 'After Step 5' in variable_tracker.

If the StorageClass is missing from the PVC, what will happen to the PVC status?

A PVC will be Deleted automatically

B PVC will be Bound immediately

C PVC will remain Pending indefinitely

D PVC will create a PV without StorageClass

💡 Hint

Refer to key_moments explanation about PVC without StorageClass.

Concept Snapshot

StorageClass enables dynamic provisioning of PersistentVolumes.
PVC specifies StorageClass to request storage.
Kubernetes triggers provisioner to create PV dynamically.
PV is bound to PVC automatically.
Pod uses PVC to access storage.
No StorageClass means no automatic provisioning.

Full Transcript

Storage classes in Kubernetes allow automatic creation of storage volumes when a user requests storage via a PersistentVolumeClaim (PVC). When a PVC is created with a StorageClass name, Kubernetes uses the provisioner defined in that StorageClass to dynamically create a PersistentVolume (PV) that matches the PVC's requirements. The PV is then bound to the PVC, making the storage available for pods to use. This process avoids manual volume creation and simplifies storage management. If no StorageClass is specified, dynamic provisioning does not occur, and the PVC remains pending until a matching PV is available.

Practice

1. What is the main purpose of a StorageClass in Kubernetes?

easy

A. To define how storage volumes are dynamically provisioned

B. To schedule pods on specific nodes

C. To manage network policies

D. To configure container resource limits

Solution

1. Step 1: Understand StorageClass role

   A StorageClass defines parameters for dynamic volume provisioning in Kubernetes.

2. Step 2: Compare with other options

   Scheduling pods, managing network policies, and resource limits are unrelated to StorageClass.

3. Final Answer:

   To define how storage volumes are dynamically provisioned -> Option A

4. Quick Check:

   StorageClass = dynamic provisioning [OK]

Hint: StorageClass controls storage creation, not pods or network [OK]

Common Mistakes:

• Confusing StorageClass with pod scheduling
• Thinking StorageClass manages network policies
• Assuming StorageClass sets container CPU/memory limits

2. Which of the following is the correct YAML snippet to specify a StorageClass named fast-storage for a PersistentVolumeClaim?

easy

A. StorageClass: fast-storage

B. storageclass: fast-storage

C. storageClassName: fast-storage

D. storage_class_name: fast-storage

Solution

1. Step 1: Recall correct field name

   The correct field in PVC spec is storageClassName with camelCase.

2. Step 2: Check other options

   Options B, C, and D use incorrect casing or underscores, which are invalid in Kubernetes YAML.

3. Final Answer:

   storageClassName: fast-storage -> Option C

4. Quick Check:

   Correct YAML key = storageClassName [OK]

Hint: Use exact camelCase 'storageClassName' in PVC spec [OK]

Common Mistakes:

• Using wrong casing like 'storageclass' or 'StorageClass'
• Replacing camelCase with underscores
• Misspelling the field name

3. Given this StorageClass YAML snippet:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: slow
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Retain

What will happen when a PersistentVolumeClaim requests storage from this class?

medium

A. The volume will not be dynamically provisioned; manual provisioning is required

B. The volume will be deleted automatically when released

C. The volume will be dynamically provisioned immediately

D. The volume will be provisioned but bound immediately without waiting

Solution

1. Step 1: Analyze provisioner field

   The provisioner is kubernetes.io/no-provisioner, meaning no dynamic provisioning.

2. Step 2: Understand reclaimPolicy and binding mode

   ReclaimPolicy is Retain (volume kept after release), and volumeBindingMode waits for pod scheduling.

3. Final Answer:

   The volume will not be dynamically provisioned; manual provisioning is required -> Option A

4. Quick Check:

   No provisioner = manual provisioning [OK]

Hint: No provisioner means no dynamic provisioning [OK]

Common Mistakes:

• Assuming dynamic provisioning happens with no-provisioner
• Confusing reclaimPolicy with provisioning behavior
• Ignoring volumeBindingMode effect

4. You created a StorageClass with volumeBindingMode: Immediate but your pods fail to schedule because volumes are not available in the node's zone. What is the likely cause and fix?

medium

A. Cause: StorageClass name mismatch; Fix: Correct PVC storageClassName

B. Cause: Reclaim policy is Retain; Fix: Change to Delete

C. Cause: Provisioner is missing; Fix: Add a provisioner

D. Cause: Immediate binding ignores pod location; Fix: Change to WaitForFirstConsumer

Solution

1. Step 1: Understand volumeBindingMode impact

   Immediate binding provisions and binds volume before pod scheduling, ignoring node zone.

2. Step 2: Identify fix

   Changing to WaitForFirstConsumer delays binding until pod scheduling, ensuring volume is in correct zone.

3. Final Answer:

   Cause: Immediate binding ignores pod location; Fix: Change to WaitForFirstConsumer -> Option D

4. Quick Check:

   Immediate binding ignores pod zone [OK]

Hint: Use WaitForFirstConsumer to bind volume after pod scheduling [OK]

Common Mistakes:

• Changing reclaimPolicy instead of binding mode
• Adding provisioner when already present
• Fixing storageClassName without checking binding mode

5. You want to create a StorageClass that dynamically provisions SSD-backed volumes with fast performance, deletes volumes when released, and delays binding until pod scheduling. Which YAML snippet correctly implements this?

hard

A. apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: fast-ssd
provisioner: kubernetes.io/aws-ebs
parameters:
type: standard
reclaimPolicy: Retain
volumeBindingMode: Immediate

B. apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: fast-ssd
provisioner: kubernetes.io/aws-ebs
parameters:
type: gp2
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer

C. apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: fast-ssd
provisioner: kubernetes.io/no-provisioner
parameters:
type: io1
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer

D. apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: fast-ssd
provisioner: kubernetes.io/aws-ebs
parameters:
type: io1
reclaimPolicy: Delete
volumeBindingMode: Immediate

Solution

1. Step 1: Identify correct provisioner and parameters

   For AWS SSD, provisioner is kubernetes.io/aws-ebs and type gp2 is general SSD.

2. Step 2: Check reclaimPolicy and binding mode

   ReclaimPolicy should be Delete to remove volumes after release; binding mode WaitForFirstConsumer delays binding until pod scheduling.

3. Step 3: Validate options

   apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: fast-ssd provisioner: kubernetes.io/aws-ebs parameters: type: standard reclaimPolicy: Retain volumeBindingMode: Immediate uses wrong type and policies; apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: fast-ssd provisioner: kubernetes.io/no-provisioner parameters: type: io1 reclaimPolicy: Delete volumeBindingMode: WaitForFirstConsumer uses no provisioner; apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: fast-ssd provisioner: kubernetes.io/aws-ebs parameters: type: io1 reclaimPolicy: Delete volumeBindingMode: Immediate uses Immediate binding which is not desired; apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: fast-ssd provisioner: kubernetes.io/aws-ebs parameters: type: gp2 reclaimPolicy: Delete volumeBindingMode: WaitForFirstConsumer matches all requirements.

4. Final Answer:

   YAML with provisioner kubernetes.io/aws-ebs, type gp2, reclaimPolicy Delete, and WaitForFirstConsumer -> Option B

5. Quick Check:

   Correct provisioner + Delete + WaitForFirstConsumer = apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: fast-ssd provisioner: kubernetes.io/aws-ebs parameters: type: gp2 reclaimPolicy: Delete volumeBindingMode: WaitForFirstConsumer [OK]

Hint: Match provisioner, parameters, reclaimPolicy, and bindingMode exactly [OK]

Common Mistakes:

• Using no-provisioner disables dynamic provisioning
• Choosing wrong volume type parameter
• Setting reclaimPolicy to Retain instead of Delete
• Using Immediate binding when delayed binding is needed