Explains OpenShift persistent storage using PersistentVolumes, PersistentVolumeClaims and StorageClasses, showing provisioning, access modes, dynamic provisioning, and how to mount volumes into pods.
Welcome to this OpenShift for Absolute Beginners lesson on storage. This article explains how OpenShift (Kubernetes) provides persistent storage for containerized applications using Persistent Volumes (PVs), Persistent Volume Claims (PVCs), and StorageClasses. You’ll learn how storage is provisioned, claimed, and mounted into pods, plus an example manifest and verification commands.Containers are ephemeral by design: when a container is removed, any data stored inside it is lost. To retain data beyond a container’s lifecycle, attach persistent storage. OpenShift uses the Kubernetes persistent volume framework to expose cluster storage to applications. Storage can come from many backends and plugins, such as local disks, iSCSI, Fibre Channel, NFS, GlusterFS, Ceph RBD, OpenStack Cinder, cloud provider disks (AWS, GCE, Azure), or VMware vSphere.
When a storage provider is added to an OpenShift cluster, it contributes PersistentVolumes to the cluster’s pool of PV resources. Projects (namespaces) request storage from this pool by creating PersistentVolumeClaims. The control plane binds a PVC to an appropriate PV. Once bound, the PV can be mounted into pods and used as durable application storage.
From the OpenShift web console you can create storage by clicking Create Storage. Give the claim a name, choose an access mode, and set the requested size. Access modes control how the volume may be mounted by nodes:
Access Mode
Behavior
Typical use case
ReadWriteOnce (RWO)
Mounted read-write by a single node (multiple pods on that node may share it).
Standard for block storage where a single node writes to the volume.
ReadWriteMany (RWX)
Mounted read-write by many nodes simultaneously (requires filesystem that supports multi-node RW).
Shared filesystems like NFS, GlusterFS, or cloud file services.
ReadOnlyMany (ROX)
Mounted read-only by many nodes.
Distributing read-only content (e.g., static files or reference data).
Add the claim in your project and then reference that claim from pod or deployment specs. If your cluster has a StorageClass that supports dynamic provisioning, creating a PVC will automatically create a matching PV. Otherwise, a cluster administrator must create a PV that satisfies the PVC.
If a StorageClass exists that supports dynamic provisioning, a PVC will trigger automatic PV creation. If no suitable StorageClass is available, the PVC will remain unbound until an admin provides a matching PV.
Below is a concise example demonstrating how to create a PVC and mount it into a Deployment. Save the manifests into files and apply them with oc apply -f <file> or kubectl apply -f <file>.PersistentVolumeClaim example (10Gi, ReadWriteOnce):
apiVersion: v1kind: PersistentVolumeClaimmetadata: name: my-app-storagespec: accessModes: - ReadWriteOnce resources: requests: storage: 10Gi # Optional: specify a StorageClass # storageClassName: standard
Verify the PVC is bound and see which PV satisfies it:
oc get pvc my-app-storage# Example output:# NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGEoc describe pvc my-app-storage# Shows bound PV name, events, and provisioning details
Key points to remember:
The manifest pattern is the same across controllers: reference the claim under volumes and mount it in volumeMounts inside the container spec.
Dynamic provisioning via StorageClass simplifies lifecycle management by automatically creating PVs.
Choose access modes based on whether multiple nodes must access the same storage and whether they need read-write access.
This concludes the overview of how storage is provisioned and consumed in OpenShift. Once a PVC is bound and mounted into a pod, data written to the mounted path persists independently of the pod lifecycle.
