Understanding Kubernetes storage
With Kubernetes volume abstraction, you can create persistent storage for pods as well as share files between containers within a pod.
For more information, see Understanding Kubernetes storage basics.
The volume that you specify in the .spec.volumes field of a pod definition is used for the pod. The volume is mounted in the container in the location that you specify in the .spec.containers.volumeMounts field.
Persistent volume and persistent volume claim
Kubernetes provides PersistentVolume and PersistentVolumeClaim Application Programming Interfaces (APIs) to abstract details of how storage is provided and consumed in an application workload.
A PersistentVolume (PV) is a piece of storage in the cluster that captures the implementation details of the storage. A PV is provisioned by a cluster administrator.
A PersistentVolumeClaim (PVC) is a request for storage. You can use a PVC to consume abstract storage resources by specifying the size and access mode.
For more information, see Persistent volumes 
.
If you have a PV provisioned in your cluster with a capacity of 500 Gi, a PVC that has a request of 700 Gi will stay unbound in your cluster until a PV is provisioned that meets this demand. When a PV is available that meets this demand, the PVC will then bind to this available PV and become ready for use.
For more information about using PVs in IBM Cloud Private, see PersistentVolume.
For more information about using PVCs in IBM Cloud Private, see PersistentVolumeClaims.
Static provisioning
A cluster administrator can use static provisioning to make existing storage devices available to a cluster. The cluster administrator creates a number of PVs that are available for consumption. The cluster administrator must know the details of the storage device, its supported configurations, and mount options.
Dynamic provisioning
You can use dynamic provisioning to order storage on demand. With dynamic provisioning, the cluster administrator does not need to pre-provision storage. Dynamic provisioning uses storage class.
For more information about dynamic provisioning in IBM Cloud Private, see Dynamic storage provisioning.
Storage Class
A storage class is used to dynamically provision volumes when there is a request for a volume. It abstracts the underlying storage platform so that you do not have to know the details of the storage platform. The cluster administrator provides pre-defined storage classes for each type of storage that is supported in your cluster. Administrators can also specify a default storage class for PVCs that do not request for any particular storage class.
For more information, see Storage Classes .
Reclaim policy
A reclaim policy releases a volume for reuse. When you no longer need a volume, you can delete the PVC objects, which allows the volume to be reclaimed. A reclaim policy of a PV tells the cluster what to do with the volume after it is released of its claim. Currently, volumes can either be retained, recycled, or deleted.
Access mode
Kubernetes supports three kinds of access modes for PVs: ReadWriteOnce, ReadOnlyMany, and ReadWriteMany.
ReadWriteOnce (RWO) - the volume can be mounted as read/write by a single node
ReadOnlyMany (ROX) - the volume can be mounted as read-only by multiple nodes
ReadWriteMany (RWX) - the volume can be mounted as read/write by multiple nodes
Container Storage Interface
Container Storage Interface (CSI) defines a standard interface for Kubernetes to include any arbitrary storage for the container workload. CSI is available as Beta and is enabled by default in your IBM Cloud Private cluster.
For more information about CSI, see Out-of-Tree Volume Plugins .
For more information about using CSI in IBM Cloud Private, see Container Storage Interface (CSI).