Home > Workload Solutions > Container Platforms > Red Hat OpenShift Container Platform > Guides > Design Guide—Red Hat OpenShift Container Platform 4.14 on AMD-powered Dell Infrastructure > OpenShift Container Platform storage
Stateful applications create a demand for persistent storage. All storage within OpenShift Container Platform 4.14 is managed separately from compute resources and from networking and connectivity infrastructure facilities.
This solution uses the following Kubernetes storage concepts:
These resources are logical constructs that the Kubernetes container infrastructure uses to maintain storage for the container ecosystem components that depend on storage. Developers and operators can deploy applications and provision or deprovision persistent storage without having any specific knowledge of the underlying storage technology.
The OpenShift Container Platform administrator is responsible for provisioning storage classes and making them available to the cluster tenants.
Storage using PVCs is consumed or used in two ways: statically or dynamically. Static storage can be attached to one or more pods by static assignment of a PV to a PVC and then to a specific pod or pods.
An administrator preprovisions PVs for Kubernetes tenants. When a user makes a persistent storage request by creating a PVC, Kubernetes finds the closest available matching PV. Static provisioning is not the most efficient method for using storage, but it might be preferred when it is necessary to restrict users from PV provisioning.
The following figure shows the static storage provisioning workflow in this solution:
Figure 5. Static storage provisioning workflow
Dynamic persistent storage provisioning
Dynamic persistent storage provisioning enables Kubernetes users to secure PV provisioning on demand. Dynamic provisioning has fully automated LUN export provisioning. For more information, see OpenShift Container Platform storage overview.
The following figure shows the dynamic storage provisioning workflow in this solution:
Figure 6. Dynamic storage provisioning workflow and benefits
After a PV is bound to a PVC, that PV cannot be bound to another PVC. This restriction binds the PV to the namespace of the binding project. A PV that has been created for dynamic use is a storage class object that functions as a cluster resource and is automatically consumed as a cluster resource.
OpenShift Container Platform supports the following PV types:
Each PV has a predetermined storage capacity that is set in its capacity parameter. The storage capacity is set or requested by a pod that is launched within the container platform. Expect the choice of control parameters to expand as the CSI API is extended and matures.
A resource provider can determine how the PV is created and set the storage control parameters. Access mode support is specific to the type of storage volume that is provisioned as a PV. Provider capabilities determine the access modes of the PV, while the capabilities of each PV determine the modes which that volume supports. For example, NFS can support multiple read/write clients, but a specific NFS PV might be configured as read-only.
Pod claims are matched to volumes with compatible access modes based on two matching criteria: access modes and size. Access modes represent a request.
For more information, see Understanding persistent storage.
Static persistent storage
The use of generic NFS or iSCSI is functional and stable. However, generic NFS and iSCSI do not contain a mechanism to provide service continuity if access to the storage subsystem fails. Also, generic NFS and iSCSI do not provide the advanced storage protection support that is available with CSI drivers. The Dell OpenShift team validated the functionality and capability of suitable storage drivers, as described in the following table:
Table 4. Generic storage capabilities
Storage type | ReadWriteOnce | ReadOnlyMany | ReadWriteMany |
HostPath (local disk) | Yes | N/A | N/A |
iSCSI (generic) | Yes | Yes | N/A |
NFS (generic) | Yes | Yes | Yes |