The OpenShift persistent storage concept
OpenShift uses the Persistent Volume (PV) concept to allow administrators to provide persistent storage for a cluster and then let developers request storage resources via Persistent Volume Claims (PVC). Thus, end users can request storage without having deep knowledge of the underlying storage infrastructure. At the same time, administrators can configure the underlying storage infrastructure and make it available to end users via the PV concept. PV resources are shared across the OpenShift cluster since any of them can (if it is allowed) potentially be used by any users/projects. On the other hand, PVC resources are specific to a project (namespace) and they are usually created and used by end users, such as developers. Once PVC resources are created, OpenShift tries to find a suitable PV resource that matches specific criteria, like size requirements, access mode (RWO, ROX, RWX), and so on. If PV has been found to satisfy the request from the PVC, OpenShift binds that PV to our PVC. Once this is complete, PV cannot be bound to additional PVCs.
Persistent Volumes:
PVs are represented by a PersistentVolume OpenShift API object, which describes an existing piece of storage infrastructure like NFS share, GlusterFS volume, iSCSI target, a Ceph RBD device, and so on. It is assumed that the underlying storage component already exists and is ready to be consumed by the OpenShift cluster. PVs have their own life cycle, which is independent of any pods that use PV.
Persistent Volume Claims:
As I mentioned previously, OpenShift users can request storage resources for their applications by means of PVCs that are defined by a PersistentVolumeClaim OpenShift API object. PVC represents a request made by an end user (usually developers). PVC consumes PV resources. A PVC contains some important information regarding resources that are requested by applications/users:
- Size needed
- Access mode
There are several access modes that can be used in the OpenShift infrastructure:
Once a PVC resource is created, OpenShift has to find a suitable PV resource and bind it to the PVC. If the binding is successful, the PVC resource can be consumed by an application.
The storage life cycle in OpenShift
The interaction between PV and PVC resources is comprised of several steps, which are shown in the following diagram:
OpenShift cluster administrators can configure dynamic PV provisioning or configure PV resources in advance. Once a user has requested a storage resource using the PVC with specific size and access mode requirements, OpenShift looks for an available PV resource. The user always gets what they ask for, at least. In order to keep storage usage to a minimum, OpenShift binds the smallest PV that matches all criteria. A PVC remains unbound until a suitable PV is found. If there is a volume matching all criteria, OpenShift software binds them together. Starting from this step, storage can be used by pods. A pod consumes PVC resources as volumes. OpenShift inspects the claim to find the bound volume and mounts that volume to the pod. For those volumes that support multiple access modes, the user specifies which mode is desired when using their claim as a volume in a pod. Users can delete PVC objects, which allows reclamation of storage resources. If PVC is deleted, the volume is considered as released but is not yet immediately available to be bound to other claims. This requires that data stored on the volumes are handled according to the reclaim policy.
The reclaim policy defines the way OpenShift understands what to do with the volume after it is released. The following reclaim policies are supported:
There are two types of supported storage in an OpenShift cluster:
- Filesystem-based storage (like NFS, Gluster, and HostPath)
- Block-based storage (like iSCSI, OpenStack Cinder, and so on)
Docker containers need file system-based storage to use as a persistent volume. This means that OpenShift can use file system-based storage directly. OpenShift needs to create a file system on block storage before using it as a persistent volume. For example, if an iSCSI block device is provided, the cluster administrator has to define what file system will be created on the block device during the PV creation process.
Source:packt