DevOps Dictionary

Kubernetes StorageClass is a Kubernetes resource that defines how persistent storage should be provisioned for PersistentVolumeClaims, or PVCs. It lets platform teams offer different storage options, such as fast SSD disks, cheaper standard disks, encrypted volumes, or zone-aware storage, without requiring application teams to know the underlying cloud or storage details.

What Kubernetes StorageClass does

A StorageClass acts as a storage profile inside a Kubernetes cluster. When a developer creates a PVC and references a StorageClass, Kubernetes uses that class to create or bind a PersistentVolume with the right settings.

For example, a cluster might provide these classes:

• fast-ssd for latency-sensitive databases such as PostgreSQL or MongoDB
• standard for general application data
• backup-retained for volumes that should not be deleted automatically
• encrypted for workloads that need encrypted disks

This gives application teams a simple interface: request storage by class, size, and access mode. The platform handles the storage backend configuration.

How StorageClass works

A StorageClass connects Kubernetes to a storage provisioner. The provisioner is usually a Container Storage Interface, or CSI, driver provided by a cloud provider or storage vendor.

Common examples include:

• Amazon EBS CSI Driver for AWS Elastic Block Store volumes
• Google Compute Engine Persistent Disk CSI Driver for GKE clusters
• Azure Disk CSI Driver for AKS clusters
• Ceph RBD CSI Driver for self-managed storage
• Longhorn for distributed block storage in Kubernetes

When a PVC requests a StorageClass, Kubernetes follows this flow:

1. A workload defines a PVC, such as a 100 GiB volume using the fast-ssd StorageClass.
2. Kubernetes checks the StorageClass configuration.
3. The configured CSI provisioner creates the backing storage resource.
4. Kubernetes creates or binds a PersistentVolume.
5. The Pod mounts the volume and uses it as persistent storage.

Key fields in a StorageClass

A typical StorageClass includes several fields that control provisioning behavior.

• provisioner: Defines the storage driver that creates the volume, such as ebs.csi.aws.com.
• parameters: Passes backend-specific settings, such as disk type, filesystem type, encryption, or IOPS options.
• reclaimPolicy: Controls what happens to the underlying volume when the PVC is deleted. Common values are Delete and Retain.
• volumeBindingMode: Controls when Kubernetes provisions and binds the volume. WaitForFirstConsumer is often safer for zonal storage because it waits until a Pod is scheduled.
• allowVolumeExpansion: Allows users to expand PVC size after creation when the storage backend supports it.

Simple StorageClass example

Here is a basic AWS EBS StorageClass example:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: gp3
provisioner: ebs.csi.aws.com
parameters:
  type: gp3
  fsType: ext4
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer

A PVC can then request this class:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: postgres-data
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: gp3
  resources:
    requests:
      storage: 100Gi

In this example, Kubernetes creates a 100 GiB EBS gp3 volume when the PVC is used by a Pod. The application does not need AWS API calls or direct disk provisioning logic.

Common use cases

• Databases on Kubernetes: Stateful workloads such as PostgreSQL, MySQL, Redis, and Elasticsearch often use PVCs backed by a StorageClass.
• Message queues: Kafka, RabbitMQ, and similar systems may need durable disks for logs and queue data.
• CI/CD systems: Build runners and artifact systems may use persistent volumes for caches or workspace data.
• Data platforms: Tools such as Apache Airflow may need persistent storage for logs, DAGs, or metadata depending on the deployment pattern. For an AWS example, see this guide to deploying Apache Airflow on Amazon EKS.
• Multi-tier storage offerings: Platform teams can expose separate classes for performance, retention, encryption, or cost profiles.

StorageClass, PersistentVolume, and PersistentVolumeClaim

These three Kubernetes concepts work together, but they solve different problems.

• StorageClass: Defines how storage should be provisioned.
• PersistentVolumeClaim: Requests storage for an application.
• PersistentVolume: Represents the actual storage volume available to the cluster.

You can think of a PVC as the request, a StorageClass as the provisioning policy, and a PersistentVolume as the resulting storage resource.

Default StorageClass

A cluster can have a default StorageClass. If a PVC does not specify storageClassName, Kubernetes can assign the default class automatically.

This is convenient, but it can also hide important decisions. For production clusters, many teams define explicit StorageClass names in workload manifests so storage behavior remains predictable across environments.

For example, a staging cluster might use cheaper standard disks, while production uses encrypted SSD-backed volumes. If both clusters rely on a default class with different behavior, the same manifest may produce different storage characteristics.

Important tradeoffs and limitations

• Storage is often zone-bound: Cloud block volumes such as EBS are usually tied to one availability zone. Use WaitForFirstConsumer to reduce scheduling conflicts.
• Access modes vary: Many block storage systems support ReadWriteOnce, meaning one node can mount the volume for writing. Shared write access, such as ReadWriteMany, usually requires a different backend like NFS, EFS, or CephFS.
• Reclaim policy affects data retention: Delete removes the backing volume when the PVC is deleted. Retain keeps it, which is safer for critical data but requires manual cleanup.
• Expansion is not universal: allowVolumeExpansion depends on CSI driver and storage backend support.
• Backups are separate: A StorageClass provisions disks. It does not replace backup, snapshot, replication, or disaster recovery planning.

Using StorageClass with infrastructure workflows

Platform teams often manage StorageClasses with GitOps, Helm, Terraform, or Crossplane. This keeps storage policy versioned and reviewable like other infrastructure code.

If your team manages Kubernetes resources with Terraform, this guide on deploying Kubernetes resources using Terraform shows the broader pattern. If you want Kubernetes to manage cloud resources directly, Crossplane can also provision cloud infrastructure through Kubernetes APIs, as shown in this guide to deploying AWS resources using Crossplane on Kubernetes.

Real-world example

Suppose your platform team runs a Kubernetes cluster for several product teams. You create three StorageClasses:

• standard: general-purpose disks with automatic deletion
• database: faster disks, volume expansion enabled, and delayed binding
• retained: disks kept after PVC deletion for safer recovery during manual operations

A payments service that runs PostgreSQL requests the database class with a 200 GiB PVC. A background worker that stores temporary cache data uses standard. A migration job that handles sensitive one-time data uses retained so the volume is not deleted by accident.

This keeps storage decisions consistent while giving each workload the right level of durability, performance, and operational safety.

Operational best practices

• Name classes by intent: Use names such as database, shared-files, or encrypted-retained instead of provider-specific names when possible.
• Set volumeBindingMode carefully: Use WaitForFirstConsumer for zonal block storage to help Kubernetes schedule Pods and volumes in the same zone.
• Document reclaim behavior: Make it clear which classes delete data and which retain it.
• Test expansion: Verify PVC resize behavior before relying on it in production.
• Plan for upgrades: CSI drivers, Kubernetes versions, and storage APIs can change. Review storage behavior during cluster upgrades. These practical Kubernetes upgrade tips for startups are useful when planning that work.

Summary

Kubernetes StorageClass defines the storage provisioning policy for PVCs. It lets teams request persistent storage through Kubernetes while platform engineers control the backend details, such as disk type, reclaim policy, binding behavior, encryption, and expansion support.

Used well, StorageClasses make stateful workloads easier to run consistently. Used carelessly, they can create data loss, scheduling issues, or unexpected storage costs. Treat them as part of your production infrastructure design, not as a default setting to ignore.