Kubernetes storage is centered on three key concepts: PersistentVolume (PV), PersistentVolumeClaim (PVC), and StorageClass. These define how storage is requested, allocated, and configured within a cluster. Under the hood, CSI (Container Storage Interface) drivers frequently handle the actual provisioning and attachment of storage. Let’s briefly look at each component and then highlight the CSI Driver’s role.
A PersistentVolume (PV) is a piece of storage in the cluster that has been provisioned (either statically by an administrator or dynamically through a StorageClass). It represents the underlying storage—such as a disk on a cloud provider or a network-attached filesystem—and is treated as a resource in the cluster, similar to a node.
A PersistentVolumeClaim (PVC) is a request for storage. Users define how much storage they need and the access mode (e.g., read-write). If an appropriate PV is available or can be dynamically provisioned (via a StorageClass), the PVC becomes “bound” to that PV. Once bound, Pods can reference the PVC to persist or share data.
Generic Ephemeral Volumes for Kubernetes is a feature introduced in Kubernetes that allows you to use CSI-driven ‘temporary’ volumes during the Pod lifecycle, similar to the This is similar to emptyDir
, but is more powerful and allows you to mount any type of CSI volume (with support for snapshots, scaling, etc.).
For more usage, please refer to Generic ephemeral volumes
emptyDir is a temporary storage volume of the empty directory type.
It is created when a Pod is dispatched to a node, and the storage is located on that node's local filesystem (node disk by default).
When a Pod is deleted, the data in emptyDir is also erased.
For more usage, please refer to Using an emptyDir
In Kubernetes, a hostPath volume is a special type of volume that maps a file or directory from the host node's filesystem directly into a Pod’s container.
It allows a pod to access files or directories on the host node.
Useful for:
Accessing host-level resources (e.g., Docker socket)
Debugging
Using pre-existing data on the node
A ConfigMap in Kubernetes is an API object used to store non-sensitive configuration data in the form of key-value pairs. It allows you to decouple configuration from application code, making your applications more portable and easier to manage.
In Kubernetes, a Secret is an API object that stores sensitive data such as:
passwords
OAuth tokens
SSH keys
TLS certificates
database credentials
Secrets help protect this data by avoiding storing it directly in Pod specifications or container images.
A StorageClass describes how volumes should be dynamically provisioned. It maps to a specific provisioner (often a CSI driver) and can include parameters such as storage tiers, performance characteristics, or other backend configurations. By creating multiple StorageClasses, you can offer various types of storage to developers.
Diagram: Relationship between PVC, PV, and StorageClass.
The Container Storage Interface (CSI) is a standard API that Kubernetes uses to integrate with storage drivers. It allows third-party storage providers to build out-of-tree plugins, meaning you can install or update a storage driver without modifying Kubernetes itself.
A CSI driver typically has two components:
When a user creates a PVC referring to a StorageClass that uses a CSI driver, the CSI driver observes that request and provisions storage accordingly (if dynamic provisioning is required). Once the storage is created, the driver notifies Kubernetes, which creates a corresponding PV and binds it to the PVC. Whenever a Pod uses that PVC, the node component of the driver handles the volume mount, making the storage available inside the container.
By leveraging PV, PVC, StorageClass, and CSI, Kubernetes enables a powerful, declarative approach to storage management. Administrators can define one or more StorageClasses to represent different storage backends or performance tiers, while developers simply request storage using PVCs—without worrying about the underlying infrastructure.