Skip to main content
StorageClasses define different classes of storage in a cluster. They specify which provisioner to use, what parameters to pass, and how volumes should behave. StorageClasses enable dynamic provisioning of PersistentVolumes.

Key Concepts

StorageClass

A cluster-scoped template that defines how storage should be provisioned.

Provisioner

The volume plugin that creates PVs (e.g., CSI drivers, cloud providers).

Binding Mode

When to provision storage: immediately or when a pod needs it.

Default Class

The StorageClass used when PVCs don’t specify one.
StorageClasses are cluster-scoped resources. They are available to all namespaces and define how storage is provisioned across the entire cluster.

Required Permissions

Key Fields

Volume Binding Modes

Use WaitForFirstConsumer for topology-aware provisioning. This ensures volumes are created in the same availability zone as the pod, preventing scheduling issues.

How to View StorageClasses

1

Select Cluster

Choose a cluster from the cluster dropdown.
2

View List

The list shows all StorageClasses in the cluster (cluster-scoped, no namespace filter).
3

Filter and Search

Use the search box to find StorageClasses by name or provisioner. Filter by binding mode (Immediate, WaitForFirstConsumer).

How to View StorageClass Details

1

Find the StorageClass

Locate the StorageClass in the list.
2

Click StorageClass Name

Click on the StorageClass name to open the detail drawer.
3

Review Details

View StorageClass information including:
  • Overview: Name, provisioner, reclaim policy, binding mode, age
  • Features: Volume expansion, default status
  • Parameters: Provisioner-specific configuration
  • Mount Options: Mount command options
  • Allowed Topologies: Zone/region constraints
  • Labels & Annotations: Metadata

How to Create a StorageClass

1

Click Create StorageClass

Click the Create StorageClass button in the page header.
2

Write YAML

Enter the StorageClass manifest in YAML format. Key fields:
  • provisioner - Volume plugin identifier (required)
  • reclaimPolicy - Delete or Retain
  • volumeBindingMode - Immediate or WaitForFirstConsumer
  • allowVolumeExpansion - true/false
  • parameters - Provisioner-specific options
3

Create

Click Create to apply the manifest.

How to Edit a StorageClass

1

Open Actions Menu

Click the actions menu (three dots) on the StorageClass row.
2

Click Edit YAML

Select Edit YAML to open the YAML editor.
3

Modify Spec

Edit the StorageClass specification. Note that most fields are immutable after creation.
4

Save

Click Update to apply changes.
Most StorageClass fields (provisioner, parameters, reclaimPolicy, volumeBindingMode) are immutable after creation. To change these, delete and recreate the StorageClass.

How to Delete a StorageClass

1

Open Actions Menu

Click the actions menu on the StorageClass row.
2

Click Delete

Select Delete from the menu.
3

Confirm

Confirm the deletion. Existing PVCs using this class will not be affected.
Deleting a StorageClass prevents new PVCs from using it for dynamic provisioning. Existing PVCs and PVs are not affected.

Default StorageClass

One StorageClass can be marked as the cluster default. PVCs that don’t specify a storageClassName will use the default class. Setting the default:
Only one StorageClass should be marked as default. If multiple are marked, behavior is undefined and may vary by Kubernetes version.

Example StorageClasses

AWS EBS (CSI)

Google Cloud Persistent Disk

Azure Disk

Local Storage

NFS (External Provisioner)

Common Provisioners

Troubleshooting

  • Verify the StorageClass exists
  • Check provisioner pods are running
  • Ensure CSI driver is properly installed
  • Check for errors in provisioner logs
  • Use volumeBindingMode: WaitForFirstConsumer
  • Configure allowedTopologies if needed
  • Verify pod has appropriate node selectors
  • Verify allowVolumeExpansion: true in StorageClass
  • Check if the provisioner supports expansion
  • Pod restart may be required for filesystem expansion
  • Check PVC conditions for resize status
  • Verify StorageClass exists: kubectl get sc
  • Check PVC storageClassName matches exactly
  • Verify provisioner has necessary permissions
  • Check provisioner logs for errors
  • Verify annotation is exactly storageclass.kubernetes.io/is-default-class: "true"
  • Ensure only one StorageClass is marked as default
  • Check PVC doesn’t explicitly set storageClassName: ""
  • Parameters are passed directly to the provisioner
  • Check provisioner documentation for valid parameters
  • Verify parameter values are strings (quoted in YAML)
  • Invalid parameters may be silently ignored

FAQ

Dynamic provisioning automatically creates PVs when PVCs are created. The StorageClass specifies the provisioner and parameters used to create the storage. No manual PV creation is needed.
Use WaitForFirstConsumer when:
  • Using multi-zone clusters
  • Storage must be in the same zone as the pod
  • Using local persistent volumes
  • Topology-aware provisioning is needed
It delays provisioning until a pod is scheduled, ensuring the volume is created in the correct location.
Most fields are immutable (provisioner, parameters, reclaimPolicy, volumeBindingMode). You can only modify labels, annotations, and allowVolumeExpansion. To change other fields, delete and recreate the StorageClass.
Existing PVCs and PVs are not affected. They retain their original settings. Only new PVCs cannot use the deleted StorageClass.
Yes, typically. Create different StorageClasses for:
  • Different performance tiers (SSD vs HDD)
  • Different reclaim policies (Delete vs Retain)
  • Different use cases (databases vs logs)
  • Different availability zones or regions
Delete: When PVC is deleted, PV and underlying storage are automatically deleted. Good for ephemeral data.Retain: PV is kept when PVC is deleted, allowing manual data recovery. The PV enters “Released” state.
Mount options are passed to the mount command when attaching volumes. Common options include ro (read-only), noatime, nodiratime. Not all provisioners support mount options.
Allowed topologies restrict where volumes can be provisioned based on node labels (typically zones/regions). This ensures volumes are only created in specific locations, useful for compliance or performance requirements.