Demo Storage Classes in Action

Every application that stores data needs storage. On Kubernetes, workloads request storage via PersistentVolumeClaims (PVCs), and the cluster provisions storage according to a StorageClass. Think of a StorageClass as a platform-provided menu of storage options: fast SSDs for databases, cheap spinning disks for archival data, cloud block volumes, or replicated storage for production workloads. Teams request the option they need and Kubernetes handles provisioning. This guide shows how to:

List and inspect StorageClasses
Demonstrate dynamic provisioning using a StorageClass (fast)
Compare reclaim behaviors (Delete vs Retain)
Apply best practices for production clusters

Keywords: Kubernetes StorageClass, dynamic provisioning, reclaim policy, PVC, PV, WaitForFirstConsumer

List available StorageClasses

Get the StorageClasses in the cluster:

kubectl get sc

Example output:

NAME         PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE        ALLOWVOLUMEEXPANSION   AGE
archive      rancher.io/local-path   Retain          WaitForFirstConsumer     false                  16m
fast         rancher.io/local-path   Delete          WaitForFirstConsumer     false                  16m
local-path   rancher.io/local-path   Delete          WaitForFirstConsumer     false                  16m

Note: The cluster’s default StorageClass (if set) is indicated by an annotation/marker in some kubectl get sc output. If a PVC omits storageClassName, Kubernetes uses the default StorageClass automatically (if one exists).

If a PVC does not set storageClassName, Kubernetes assigns the default StorageClass (if one exists). This behavior is important in production clusters to avoid unexpected storage types being provisioned.

Inspect a StorageClass

To view details for the fast StorageClass:

kubectl describe storageclass fast

Example output (trimmed):

Name:                  fast
IsDefaultClass:        No
Provisioner:           rancher.io/local-path
ReclaimPolicy:         Delete
VolumeBindingMode:     WaitForFirstConsumer
AllowVolumeExpansion:  <unset>
Parameters:            <none>
MountOptions:          <none>
Events:                <none>

Key StorageClass fields and what they mean:

Field	Description	Typical Values / Notes
`Provisioner`	The CSI/plugin responsible for creating volumes	e.g., `rancher.io/local-path`, `kubernetes.io/aws-ebs`, `ebs.csi.aws.com`
`ReclaimPolicy`	What happens to the underlying PV/storage when the PVC is deleted	`Delete` (auto-remove), `Retain` (manual cleanup)
`VolumeBindingMode`	When the PV is provisioned relative to Pod scheduling	`Immediate` or `WaitForFirstConsumer` (prevents cross-zone leaks)
`AllowVolumeExpansion`	Whether PVCs can request more capacity after creation	`true` / `false`
`Parameters`	Provisioner-specific options	Varies per driver

Volume binding mode note: WaitForFirstConsumer delays provisioning until a Pod using the PVC is scheduled — this avoids provisioning in the wrong zone/node and is highly recommended in multi-zone clusters.

Demonstrate dynamic provisioning (fast StorageClass)

Create a PVC that requests 1Gi using the fast StorageClass. Save this as pvc-fast.yaml:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-storage
  namespace: storage
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: fast
  resources:
    requests:
      storage: 1Gi

Apply the PVC:

kubectl apply -f pvc-fast.yaml
# persistentvolumeclaim/app-storage created

Watch the PVC in the storage namespace:

kubectl get pvc -n storage -w

Because VolumeBindingMode is WaitForFirstConsumer, the PVC will initially be Pending until a Pod mounts it. Create a Pod that consumes the PVC to trigger provisioning:

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: app
  namespace: storage
spec:
  containers:
  - name: app
    image: nginx
    volumeMounts:
    - mountPath: /data
      name: storage
  volumes:
  - name: storage
    persistentVolumeClaim:
      claimName: app-storage
EOF
# pod/app created

After scheduling, the PVC should transition from Pending to Bound:

NAME          STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
app-storage   Bound    pvc-1dcc29bc-a8a1-4c97-a5f9-bb0e19dadc7   1Gi        RWO            fast           30s

A PV is created dynamically to satisfy the claim:

kubectl get pv

Example:

NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STORAGECLASS   STATUS   CLAIM
pvc-1dcc29bc-a8a1-4c97-a5f9-bb0e19dadc7    1Gi        RWO            Delete           fast           Bound    storage/app-storage

Explanation: Because the fast StorageClass has ReclaimPolicy: Delete, the underlying storage will be deleted automatically when the PVC (and its binding) is removed.

Demonstrate reclaim policy difference: Retain (archive StorageClass)

The archive StorageClass in this cluster uses ReclaimPolicy: Retain. Create a PVC using that class. Save this as pvc-archive.yaml:

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

Apply it:

kubectl apply -f pvc-archive.yaml
# persistentvolumeclaim/archive-storage created

Create a Pod that mounts the archive-storage claim:

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: archive-app
  namespace: storage
spec:
  containers:
  - name: app
    image: nginx
    volumeMounts:
    - mountPath: /data
      name: storage
  volumes:
  - name: storage
    persistentVolumeClaim:
      claimName: archive-storage
EOF
# pod/archive-app created

After scheduling, the PVC will bind and a PV will be provisioned for the archive StorageClass. The PV will show RECLAIM POLICY: Retain:

kubectl get pv

Example (trimmed):

NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STORAGECLASS   STATUS   CLAIM
pvc-aaaa1111-...                           500Mi      RWO            Retain           archive        Bound    storage/archive-storage

What happens on deletion with different reclaim policies

For fast (ReclaimPolicy: Delete)
- Delete the Pod and the PVC:
  kubectl delete pod -n storage app kubectl delete pvc -n storage app-storage
- Result: The PV and the underlying storage resource are deleted automatically.
For archive (ReclaimPolicy: Retain)
- Delete the Pod, then delete the PVC:
  kubectl delete pod -n storage archive-app kubectl delete pvc -n storage archive-storage
- Result: The PV remains in the cluster and moves to Released state. The underlying data is preserved and requires administrator action to reclaim or reuse the volume.

Example after deleting a PVC for a Retain PV:

kubectl get pv

Example output:

NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STORAGECLASS   STATUS     CLAIM
pvc-aaaa1111-...                           500Mi      RWO            Retain           archive        Released   <none>

When a PV is Released with Retain, an administrator must:

Inspect and back up data if needed
Clean or wipe data to make the volume reusable
Remove or update claimRef on the PV to allow re-binding
Or manually delete the underlying storage resource

Choose reclaim policies based on workload needs:

Use Retain for critical, stateful workloads (databases, logs) to prevent accidental data loss.
Use Delete for ephemeral or test workloads to automate cleanup. Also confirm correct access modes (ReadWriteOnce, ReadWriteMany) and zone affinity by using WaitForFirstConsumer in multi-zone clusters.

Recap / Best practices

Inspect StorageClasses before creating PVCs:
- kubectl get sc and kubectl describe sc <name>
Understand reclaim behavior:
- Delete — automated cleanup
- Retain — manual intervention required
Use WaitForFirstConsumer to avoid cross-zone provisioning in multi-zone clusters.
Prefer explicitly setting storageClassName in PVCs unless you intentionally rely on a default StorageClass.
Confirm access modes and size requirements match application needs.
Monitor resource lifecycle:
- kubectl get pvc -n <ns> -w
- kubectl get pv

Links and references

Explore your cluster’s StorageClasses, create PVCs and Pods, and observe how Kubernetes dynamically provisions and manages storage according to StorageClass settings.

Course Introduction

Platform Architecture and Infrastructure

GitOps and Continuous Delivery

Platform APIs and Self-Service Capabilities

Observability and Operations

Security and Policy Enforcement

Conclusion

Demo Storage Classes in Action

List available StorageClasses

Inspect a StorageClass

Demonstrate dynamic provisioning (fast StorageClass)

Demonstrate reclaim policy difference: Retain (archive StorageClass)

What happens on deletion with different reclaim policies

Recap / Best practices

Links and references

Watch Video

Practice Lab

​List available StorageClasses

​Inspect a StorageClass

​Demonstrate dynamic provisioning (fast StorageClass)

​Demonstrate reclaim policy difference: Retain (archive StorageClass)

​What happens on deletion with different reclaim policies

​Recap / Best practices

​Links and references

Watch Video

Practice Lab

List available StorageClasses

Inspect a StorageClass

Demonstrate dynamic provisioning (fast StorageClass)

Demonstrate reclaim policy difference: Retain (archive StorageClass)

What happens on deletion with different reclaim policies

Recap / Best practices

Links and references