96 Red Hat OpenShift and IBM Cloud Paks on IBM Power Systems: Volume 1
Ephemeral storage
Container images are stored locally on the nodes running Red Hat OpenShift Container 
Platform pods. 
When Docker run time is used, the /var/lib/docker mount point is used by active containers 
and pods. This local storage is where the node maintains a copy of container images that are 
pulled from a container registry. This mount point is managed by docker-storage and it uses 
the following naming format: /var/lib/docker/overlay2/<layer-id> and 
/var/lib/docker/containers/<container-id>.
Persistent storage
Persistent Volume Claims (PVC) are used to store the application data. These claims can be 
added to the environment manually or provisioned dynamically by using a StorageClass 
object.
Storage classes
The StorageClass resource object describes and classifies different types of storage that can 
be requested. It also provides a means for passing parameters to the backend for dynamically 
provisioned storage on demand. 
StorageClass objects can also serve as a management mechanism for controlling different 
levels of storage and access to the storage. Cluster Administrators (cluster-admin) or Storage 
Administrators (storage-admin) define and create the StorageClass objects that users can 
use without needing any intimate knowledge about the underlying storage volume sources. 
Therefore, the naming of the storage class that is defined in the StorageClass object must be 
useful in understanding the type of storage it maps, whether that is storage from PowerVC 
Cinder or from other storage provider.
Persistent Volumes
PersistentVolumes (PV) objects provide pods with non-ephemeral storage by configuring and 
encapsulating underlying storage sources. A PersistentVolumeClaim (PVC) abstracts an 
underlying PV to provide provider-independent storage to OpenShift resources. When 
successfully fulfilled by the system, a PVC mounts the persistent storage to a specific 
directory (mountPath) within one or more pods. From the container perspective, the 
mountPath is connected to the underlying storage mount points by a regular bind mount.
FlexVolumes
FlexVolume is known as an out-of-tree plug-in interface because it is developed outside the 
main Kubernetes source code. The FlexVolume interface enables users to write their own 
drivers. These drivers can be written in any programming or scripting language.
When an application that is running on OpenShift needs a persistent volume, it submits a 
persistent volume claim to the PowerVC FlexVolume driver. The PowerVC FlexVolume call is 
translated into a Cinder API call to create a volume. When the volume is ready, it is presented 
back to OpenShift and attached to the requesting pod. 
The persistent volume claim needs to include only the volume size and access mode. The 
backend implementation information about how and where the volume is created are handled 
by PowerVC. The OpenShift API abstracts them from the user that is making the resource 
claim.
Note: For more information about the PowerVC FlexVolume, see this web page.