Lab Solution Storage Class

This lesson walks through a hands-on lab for StorageClasses, PersistentVolumes (PVs), and PersistentVolumeClaims (PVCs) in Kubernetes. Each step includes the exact commands and example outputs you can use to validate the cluster state. Links to relevant Kubernetes documentation are included at the end.

How many StorageClasses exist in the cluster?

List StorageClasses with either the short or full command:

# short form
kubectl get sc

# or full
kubectl get storageclass

Example output when the cluster initially had only the default StorageClass:

NAME                 PROVISIONER           VOLUMEBINDINGMODE        ALLOWVOLUMEEXPANSION   AGE
local-path (default) rancher.io/local-path  WaitForFirstConsumer    false                  15m

After creating additional StorageClasses, you might see multiple entries. Example consolidated output (trimmed for clarity):

kubectl get sc

NAME                         PROVISIONER                      VOLUMEBINDINGMODE        ALLOWVOLUMEEXPANSION   AGE
local-path (default)         rancher.io/local-path            WaitForFirstConsumer     false                  15m
local-storage                kubernetes.io/no-provisioner    WaitForFirstConsumer     false                  6s
portworx-io-priority-high    kubernetes.io/portworx-volume   Immediate                false                  6s

Summary table (sample output columns):

StorageClass Name	Provisioner	Volume Binding Mode	Allow Volume Expansion
local-path (default)	`rancher.io/local-path`	`WaitForFirstConsumer`	`false`
local-storage	`kubernetes.io/no-provisioner`	`WaitForFirstConsumer`	`false`
portworx-io-priority-high	`kubernetes.io/portworx-volume`	`Immediate`	`false`

Which StorageClass does not support dynamic provisioning?

A StorageClass that uses the kubernetes.io/no-provisioner provisioner will not dynamically provision volumes. In the example output above, local-storage uses kubernetes.io/no-provisioner, so it does not support dynamic provisioning and relies on pre-provisioned PVs.

What is the volume binding mode for the local-storage StorageClass?

local-storage uses the WaitForFirstConsumer volumeBindingMode. This delays binding until a Pod that consumes the PVC is scheduled, ensuring the PV is bound on a node that actually has access to the underlying local storage.

What is the provisioner for the StorageClass named portworx-io-priority-high?

From the sample output, the provisioner for portworx-io-priority-high is kubernetes.io/portworx-volume.

Is there a PersistentVolumeClaim consuming the PersistentVolume named local-pv?

List PVs and PVCs:

kubectl get pv
kubectl get pvc

Example output before creating any PVCs:

kubectl get pv

NAME       CAPACITY  ACCESS MODES  RECLAIM POLICY  STATUS      CLAIM  STORAGECLASS   AGE
local-pv   500Mi     RWO           Retain          Available         local-storage  110s

kubectl get pvc

No resources found in default namespace.

Initially there are no PVCs consuming local-pv; the PV is Available and unbound.

Create a PersistentVolumeClaim named local-pvc that should bind to local-pv

To bind a PVC to an existing PV:

Request the same or smaller capacity than the PV.
Use a compatible access mode (e.g., ReadWriteOnce).
Specify the same storageClassName as the PV (local-storage in this example).

Create pvc.yaml:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: local-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 500Mi
  storageClassName: local-storage

Apply the manifest:

kubectl create -f pvc.yaml
# Output:
# persistentvolumeclaim/local-pvc created

Check the PVC status:

kubectl get pvc
# Example:
# NAME        STATUS    VOLUME     CAPACITY  ACCESS MODES  STORAGECLASS    AGE
# local-pvc   Pending              500Mi     RWO           local-storage   4s

Why is the PVC in Pending even though the PV exists and matches?

Describe the PVC to view events:

kubectl describe pvc local-pvc

Relevant events example:

Events:
  Type    Reason               Age                 From                         Message
  ----    ------               ----                ----                         -------
  Normal  WaitForFirstConsumer  6s (x4 over 49s)   persistentvolume-controller  waiting for first consumer to be created before binding

Because the StorageClass local-storage uses volumeBindingMode: WaitForFirstConsumer, binding is intentionally delayed until a Pod that consumes the PVC is created and scheduled. The PVC remains Pending until an associated Pod exists so the scheduler can ensure the Pod is placed on a node that can access the PV.

StorageClasses with WaitForFirstConsumer delay binding (and dynamic provisioning) until a Pod uses the PVC. This is typical for local volumes to ensure the PV is bound on a node that actually has the storage.

Create a Pod that consumes local-pvc

Create nginx-pod.yaml that mounts the claim at /var/www/html:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    run: nginx
spec:
  containers:
  - name: nginx
    image: nginx:alpine
    volumeMounts:
    - name: local-pvc-volume
      mountPath: /var/www/html
  volumes:
  - name: local-pvc-volume
    persistentVolumeClaim:
      claimName: local-pvc
  restartPolicy: Always

Create the Pod:

kubectl apply -f nginx-pod.yaml
# or
kubectl create -f nginx-pod.yaml

Verify Pod and PVC status:

kubectl get pods
# Example:
# NAME    READY   STATUS    RESTARTS   AGE
kubectl get pvc
# Example:
# NAME        STATUS   VOLUME     CAPACITY  ACCESS MODES  STORAGECLASS    AGE
# local-pvc   Bound    local-pv   500Mi     RWO           local-storage   1m

When the Pod that uses the PVC is created, the PVC transitions from Pending to Bound and the PV becomes bound to the claim.

Create a new StorageClass delayed-volume-sc that uses no-provisioner and delayed binding

Create delayed-volume-sc.yaml:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: delayed-volume-sc
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer

Create the StorageClass:

kubectl create -f delayed-volume-sc.yaml
# Output:
# storageclass.storage.k8s.io/delayed-volume-sc created

Verify StorageClasses:

kubectl get sc

# Example:
# NAME                         PROVISIONER                      VOLUMEBINDINGMODE        ALLOWVOLUMEEXPANSION   AGE
# local-path (default)         rancher.io/local-path            WaitForFirstConsumer     false                  26m
# local-storage                kubernetes.io/no-provisioner    WaitForFirstConsumer     false                  10m
# portworx-io-priority-high    kubernetes.io/portworx-volume   Immediate                false                  10m
# delayed-volume-sc            kubernetes.io/no-provisioner    WaitForFirstConsumer     false                  3s

The delayed-volume-sc StorageClass uses the no-provisioner provisioner and WaitForFirstConsumer binding, suitable for clusters that rely on pre-provisioned local PVs and want to delay binding until Pod scheduling. Links and references

Introduction

Core Concepts

Scheduling

Logging & Monitoring

Application Lifecycle Management

Cluster Maintenance

Security

Storage

Networking

Design and Install a Kubernetes Cluster

Install "Kubernetes the kubeadm way"

Troubleshooting

Helm Basics (2025 Updates)

Kustomize Basics (2025 Updates)

Other Topics

Mock Exams

Lab Solution Storage Class

Watch Video