Before we meet storage classes, we need to understand why containers and storage do not mix naturally.

Containers are forgetful

A container is a small, portable box that holds a running program. By design, a container is disposable. When it stops, everything it wrote inside its own private space is thrown away. This is wonderful for stateless programs, such as a web page server that keeps no records, because a fresh copy can start at any time and behave exactly the same.

The trouble begins with programs that must remember things, such as databases, message queues and file storage services. If a database container is restarted and forgets every customer order, the business is in serious trouble. These programs need a place to keep data that outlives any single container.

Containers also move around

In Kubernetes, a container may be restarted on a different computer at any time. If its data sits on the disk of the old computer, the new copy cannot see it. So persistent storage must be something that can be reached from wherever the container lands, or that Kubernetes can move along with it.

A quick tour of the building blocks that storage depends on.

Two ideas here are especially important for storage. First, nodes can be in different zones, which are separate physical locations with their own power and network. Second, controllers do the actual work behind the scenes. Storage in Kubernetes is largely a story of controllers reacting to your requests.

The three basic storage ideas that come before storage classes.

Volume

A volume is a folder made available to the containers of a pod. Some volumes are temporary and vanish when the pod is removed. Others point to storage that lives outside the pod. A volume solves the problem of sharing files between containers in the same pod, and, when backed by real storage, of keeping files alive.

Persistent Volume

A persistent volume, often shortened to PV, is a piece of real storage that has been made available to the cluster. It might be a cloud disk, a network file share or a disk attached to a server. The important point is that a persistent volume exists independently of any pod. It is a resource of the cluster, like a node.

Persistent Volume Claim

A persistent volume claim, shortened to PVC, is a request for storage made by a user or application. It says, in effect, “I need this much space, with this kind of access.” Kubernetes then finds or creates a matching persistent volume and attaches the claim to it. The application only ever talks about the claim, never about the underlying disk.

The missing piece that lets Kubernetes create disks automatically on demand.

The plain definition

A storage class is a cluster-wide object that describes a kind of storage available in the cluster, and how Kubernetes should create it. It has a name, such as “fast” or “standard”, and it records who provides the storage, which settings to use, and what to do with the disk when it is no longer needed.

When a claim names a storage class, Kubernetes uses the class as a recipe: it asks the provider to create a brand-new disk exactly as the class describes, and then connects the disk to the claim. No administrator has to prepare anything in advance.

Why it exists

Before storage classes, administrators had to create every persistent volume by hand and then wait for developers to claim them. This was slow and error-prone. It also wasted money, because pre-made disks sat unused. Storage classes let developers request storage themselves, while administrators keep control by deciding which types are on the menu.

There are two ways to get a persistent volume. Storage classes power the modern one.

flowchart LR
    subgraph Static
        A1["Administrator creates disk and persistent volume"] --> B1["User submits claim"]
        B1 --> C1["Kubernetes matches claim to existing volume"]
    end
    subgraph Dynamic
        A2["Administrator defines storage class once"] --> B2["User submits claim naming the class"]
        B2 --> C2["Provisioner creates a new disk on demand"]
        C2 --> D2["Volume is bound to the claim"]
    end
        

Every storage class is built from a handful of fields. Learn them once and you can read any class.

Let us follow one storage request all the way from a developer’s keyboard to a mounted folder.

Step one: the claim is created

A developer creates a persistent volume claim. It states the size needed, the type of access and the name of the storage class. The API server checks permissions and stores the claim. At this moment, the claim is in a waiting state, because nothing has been provided yet.

Step two: the provisioner notices

A helper program, usually installed with the storage driver, watches for new claims that name a class it is responsible for. When it sees one, it reads the class to learn the settings, and then calls the storage provider to create a real disk of the requested size.

Step three: the persistent volume appears

Once the provider confirms the disk exists, the helper creates a persistent volume object that describes it. Kubernetes then binds the volume and the claim together. From this moment they belong to each other exclusively, and the claim reports that it is bound.

Step four: the pod uses the claim

When a pod referring to the claim is placed on a node, the storage driver attaches the disk to that node and prepares it, for example by formatting it if it is new. The node then makes the disk appear as a folder inside the containers. The application simply reads and writes files there.

sequenceDiagram
    participant Dev as Developer
    participant API as API Server
    participant Prov as Provisioner
    participant Cloud as Storage Provider
    participant Node as Node and Kubelet
    Dev->>API: Create claim naming a storage class
    API-->>Prov: Notify about new claim
    Prov->>API: Read storage class settings
    Prov->>Cloud: Create disk with those settings
    Cloud-->>Prov: Disk ready
    Prov->>API: Create persistent volume and bind to claim
    Dev->>API: Create pod that uses the claim
    API-->>Node: Schedule pod
    Node->>Cloud: Attach disk to node
    Node->>Node: Prepare and mount disk into containers
        

A surprisingly important setting that decides whether pods get stuck.

Immediate binding

With immediate binding, the disk is created as soon as the claim appears, before any pod exists. This is simple, but it has a hidden risk. Many disks are tied to a single zone. If the disk is created in one zone and the pod later lands on a node in another zone, the pod cannot use the disk and stays stuck in a waiting state.

Wait for first consumer

With this mode, Kubernetes waits until a pod that uses the claim is being placed on a node. It then creates the disk in the same zone as that node. This ensures the disk and the pod are compatible from the start. It is the recommended choice for storage that is tied to a zone or to a specific node.

flowchart TD
    C["Claim created"] --> M{"Binding mode?"}
    M -- "Immediate" --> I["Disk created at once in some zone"]
    I --> P1["Pod scheduled later"]
    P1 --> R{"Same zone as disk?"}
    R -- "No" --> S["Pod stuck waiting"]
    R -- "Yes" --> OK1["Pod runs"]
    M -- "Wait for first consumer" --> W["Wait for a pod to be scheduled"]
    W --> Z["Disk created in the pod's zone"]
    Z --> OK2["Pod runs"]
        

The setting that decides whether deleting a claim also destroys your data.

When a claim is deleted, Kubernetes must decide what to do with the disk that was bound to it. This choice is called the reclaim policy, and it is set in the storage class. Understanding it can save a company from a very painful surprise.

Two more choices that shape how storage can be used and grown.

Access modes

An access mode describes how many nodes or pods may use a volume at the same time, and whether they may write. It is requested by the claim, and it must be supported by the underlying storage.

Volume expansion

Data grows. When a storage class allows expansion, a user can edit an existing claim and request a larger size. The provider enlarges the disk, and the file system is grown to use the new space, sometimes while the pod is still running, sometimes after a restart, depending on the driver.

Expansion works in one direction only. You can make a claim bigger, but you cannot shrink it. If you request too much, you pay for it until you move the data to a smaller volume by hand. This is why many teams start modestly and grow when monitoring shows the need.

How clusters offer a sensible choice to people who do not ask for anything specific.

The default storage class

One storage class in a cluster can be marked as the default, using a special annotation. When a claim does not name any class at all, Kubernetes silently gives it the default. This makes life easy for beginners, who can ask for space without learning the menu.

There should be only one default at a time. If a claim explicitly names an empty class, Kubernetes understands that dynamic creation is not wanted and looks only for existing volumes to match. This small difference between “no class named” and “empty class named” surprises many people.

Building tiers

Because a class is just a named recipe, administrators can create several, each representing a service level. A typical menu might look like this.

Who actually builds the disk? The answer is a plug-in system.

The problem it solves

There are countless storage systems in the world: cloud disks, network appliances, software-defined storage, local drives. If Kubernetes had to include code for every one, it would be enormous and slow to update. Instead, Kubernetes defines a standard plug-in interface called the Container Storage Interface, or CSI, and lets each storage vendor supply a driver.

What a driver does

A CSI driver knows how to create and delete disks, attach them to nodes, format them, mount them into pods, expand them and take snapshots. The storage class points to a driver by name through its provisioner field, and passes settings through the parameters field.

flowchart LR
    K["Kubernetes core"] --> CSI["Container Storage Interface"]
    CSI --> D1["Cloud disk driver"]
    CSI --> D2["Network file system driver"]
    CSI --> D3["Software-defined storage driver"]
    CSI --> D4["Local disk driver"]
    D1 --> S1["Block disks in the cloud"]
    D2 --> S2["Shared file storage"]
    D3 --> S3["Distributed storage cluster"]
    D4 --> S4["Disks in the node itself"]
        

Kinds of storage a class might describe

From request to retirement, storage passes through clear stages.

Most beginners only see the middle steps. Experienced engineers plan for the first and last, because the class design decides cost and safety, and the reclaim step decides whether data survives a mistake.

Databases and similar programs need special care, and Kubernetes has a dedicated tool for them.

Why a plain Deployment is not enough

A Deployment treats its pods as interchangeable. If several pods share one claim, they all fight over the same disk, and most block disks only allow one node at a time. Stateful applications need each copy to have its own stable identity and its own private storage.

The StatefulSet approach

A StatefulSet is a manager object designed for such programs. It gives each pod a permanent name and number. It can also carry a claim template, which means every pod gets its own personal claim created from the chosen storage class. If a pod is rebuilt, it reconnects to the very same claim and finds its data waiting.

flowchart TD
    SS["StatefulSet with a claim template"] --> P0["Pod number 0"]
    SS --> P1["Pod number 1"]
    SS --> P2["Pod number 2"]
    P0 --> C0["Own claim 0"]
    P1 --> C1["Own claim 1"]
    P2 --> C2["Own claim 2"]
    C0 --> V0["Own disk 0"]
    C1 --> V1["Own disk 1"]
    C2 --> V2["Own disk 2"]
        

Data at rest deserves protection, and storage classes are a good place to enforce it.

Encryption at rest

Many drivers accept a parameter that turns on disk encryption, sometimes with a key managed by a key service. By putting this in the storage class, an administrator ensures that every disk created from it is encrypted, without relying on each developer to remember.

Control who can create claims

Anyone allowed to create claims can cause disks to be created, which costs money and consumes capacity. Role-based access control decides who may do so. Combine it with limits, called resource quotas, that cap the total storage a namespace may request.

Control who can define classes

Storage classes are cluster-wide, so only trusted administrators should be able to create or edit them. A careless class could send data to an insecure location or use a dangerous reclaim policy.

Isolation between teams

Claims live in namespaces and cannot be used by pods in other namespaces. The underlying volumes, however, are cluster resources. Good policy prevents users from binding directly to volumes that belong to someone else.

Protect backups and snapshots

Snapshots of volumes contain the same data as the volumes, and must be protected in the same way. Keep them encrypted and limit who may create, view or restore them.

flowchart TD
    A["Trusted administrators define storage classes"] --> B["Classes enforce encryption and reclaim policy"]
    B --> C["Access control limits who may create claims"]
    C --> D["Quotas cap storage per namespace"]
    D --> E["Snapshots and backups are encrypted and restricted"]
    E --> F["Audit logs record who created or deleted storage"]
        

Storage problems are quiet until they are suddenly loud. Watch them early.

What to monitor

Common problems and their usual causes

Patterns are proven habits. Anti-patterns are popular mistakes that keep costing teams.

Patterns worth adopting

Anti-patterns to avoid

An honest look at what storage classes give you, and what they cost.

The main lesson is that a storage class makes provisioning easy, but it does not make data management easy. Backups, capacity planning and clean-up remain the team’s responsibility.

A checklist of habits that separate steady clusters from surprising ones.

Best practices

• Offer a small menu of clear classes — name them by purpose so developers can choose without expert knowledge.
• Mark exactly one default — and make sure it is safe and sensible for everyday use.
• Use wait for first consumer — for any storage tied to a zone or a node.
• Choose reclaim policy on purpose — delete for disposable data, retain for valuable data.
• Allow expansion — so growth does not require copying data to a new disk.
• Enable encryption in the class — so every disk is protected without depending on memory.
• Set quotas and alerts — cap storage per namespace and warn before disks fill.
• Back up and rehearse restores — snapshots are only useful if restoring works.

Common mistakes

How the ideas in this guide appear in everyday engineering.

A persistent volume is an actual piece of storage in the cluster. A storage class is a template describing how such volumes should be created on demand. The class is the recipe, and the volume is the dish.

No. If administrators pre-create persistent volumes, claims can bind to them without any class doing dynamic creation. However, most modern clusters use storage classes because they remove manual work.

Common reasons include a misspelled class name, no default class, a driver that is not running, or a binding mode that waits for a pod. Check the events on the claim for a clear explanation.

Not directly. The class of a claim is fixed once set. To move to a different class, you create a new claim with the new class and copy the data across, often using snapshots or a migration tool.

It depends on the reclaim policy. With delete, the disk and data are removed. With retain, the disk is kept and an administrator decides what to do with it. Always check the policy before deleting anything important.

No. Kubernetes supports growing a claim only. To shrink, you must create a smaller volume and move the data yourself.

Many cloud disks exist in one zone only and can be attached only to nodes in that zone. If a pod runs in a different zone, it cannot reach the disk. The wait-for-first-consumer mode avoids this by creating the disk where the pod runs.

Only if the storage and its access mode allow it. Network file systems usually support shared reading and writing. Simple block disks generally allow one node at a time.

Exactly one should be marked default. Having several or none makes behaviour unpredictable for claims that do not name a class.

List your storage classes and check the reclaim policy and binding mode of each. Then make sure critical data uses a protected class and that backups exist and have been tested.

Containers forget, but applications often must remember. Kubernetes solves this with persistent volumes, claims and storage classes. A claim is a request for space, a persistent volume is the real storage, and a storage class is the recipe that lets Kubernetes create that storage on demand through a driver. Choices such as binding mode, reclaim policy, access mode and expansion decide where a disk lives, whether it survives deletion, who can share it and whether it can grow.

Treat storage classes as the menu you offer your developers. Keep it small, name it clearly, protect what is valuable, and watch what is growing. Do that, and Kubernetes storage becomes a quiet, dependable part of your platform rather than a source of midnight surprises.