Persistent storage overview

Persistent volumes are used to store persistent data for pods that need to maintain and share the state between multiple instances. They are also used to share files between two or more pods.

Persistent volumes in Red Hat® OpenShift® have specific storage that is allocated to them. The Red Hat OpenShift Container Platform uses the Kubernetes persistent volume (PV) framework so that cluster administrators can provision persistent storage for a cluster. Applications can use persistent volume claims (PVCs) to request persistent volume resources.

Red Hat OpenShift supports various storage types to create the persistent volumes. A cluster administrator can provision persistent volumes either statically or dynamically for file-based storage.

FTM supports both static and dynamic provisioning of storage types for all the PVs. Storage types such as NFS must follow these restrictions when they are used with FTM.

Red Hat OpenShift Container Platform storage resources

A PersistentVolume object is a storage resource in an Red Hat OpenShift Container Platform cluster. Your cluster administrator provisions storage by creating PersistentVolume objects from sources such as NFS mounts or cloud-based shared storage. For more information about creating PVs that use NFS storage, see Persistent storage by using NFS.

A PersistentVolumeClaim is a request for a resource with specific attributes, such as storage size. A PersistentVolume is a specific resource. A process matches a claim to an available volume and binds them together. This process allows the claim to be used as a volume in a pod. Red Hat OpenShift Container Platform finds the volume that backs the claim and mounts it into the pod.

On their own, persistent volume resources are not scoped to any single project. They can be shared across the entire Red Hat OpenShift Container Platform cluster and claimed from any project.

Persistent volume categories

Persistent volumes are separated into the following categories:

Precreated static persistent volumes: Many paths inside the FTM pods need to be accessible outside the Red Hat OpenShift environment. The PVs used for such paths need to be shared outside the cluster for users to get or update the files.
Dynamic persistent volumes: These persistent volumes do not require user access. Therefore, they cannot be created with any shared storage type. Red Hat OpenShift dynamically creates these PVs during the FTM deployment. FTM is tested with rook-ceph storage for dynamic PVs.

For more information, see Persistent volumes for your FTM offering.

Persistent volume cleanup

Both statically and dynamically provisioned persistent volumes (PV) must be monitored to ensure that the storage capacity on each volume is not exceeded. A periodic cleanup of the unused files on the persistent volumes is needed to avoid problems.

For example, the debug data persistent volume is used to store any core memory dump files that the application or system generates. Some system error or failure might cause repeated core memory dumps to be generated, which causes the debug data persistent volume to fill up. Therefore, the debug data PV needs to be monitored and the core memory dump files need to be periodically cleaned up or moved.

Persistent volume best practices

The following list describes some best practices to use for persistent volumes.

Use a separate volume or drive for each persistent volume if you are provisioning static storage: To help avoid problems, create and mount an individual volume or drive for each persistent volume.