Home > Workload Solutions > Container Platforms > Red Hat OpenShift Container Platform > Archive > Design Guide—Red Hat OpenShift Container Platform 4.2 > CSI and persistent storage
All storage within OpenShift Container Platform 4.x is managed separately from compute (worker node) resources and from all networking and connectivity infrastructure facilities. The introduction of the CSI API is designed to abstract storage use and to enable storage portability.
The CSI facility adds new storage capabilities to the Kubernetes container platform. CSI enables the deployment of new storage types without the need for changes to Kubernetes platform code.
The CSI API introduces two new resources: PersistentVolume (PV) and PersistentVolumeClaim (PVC) objects. In addition, the Storage Classes or StatefulSet concepts describe the types of storage that might be provisioned for container use within a container platform.
These resources represent logical constructs that are used within the Kubernetes container infrastructure to maintain storage for all the container ecosystem components that depend on storage. Developers and operators can deploy applications without having specific technical knowledge of the underlying storage technology.
The OpenShift Container Platform administrator is responsible for provisioning targeted storage PVs, making them available for container platform use. PVs are unrelated to pods and pod storage life cycles. PVs are internal objects against which PVCs are created.
All pods are deployed as part of a project. PVCs are specific to a project. PVCs enable use of preferred storage types that are either integrated into the OpenShift Container Platform or located in external storage (sometimes referred to as pre-existing storage).
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.
After a PV is bound to a PVC, the PV cannot be bound to another PVC. This restriction effectively binds the PV to a single namespace, that of the binding project. A PV that has been created for dynamic use is a storage class object that functions as, and consumed automatically as, a cluster resource.
OpenShift Container Platform natively supports the following PV types:
The CSI API extends the storage types that can be used within an OpenShift container platform.
Each PV has predetermined storage capacity that is set in its capacity definition parameter. The storage capacity can be 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 as it matures.
A resource provider can determine how the PV is created and can 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 PV’s access modes, while the capabilities of each PV determine the modes that are supported by that particular volume. 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. A pod claim’s access modes represent a request.