$ oc get storageclass
OpenShift Container Platform is capable of provisioning persistent volumes (PVs) using the Container Storage Interface (CSI) driver for OpenStack Cinder.
Familiarity with persistent storage and configuring CSI volumes is recommended when working with a Container Storage Interface (CSI) Operator and driver.
To create CSI-provisioned PVs that mount to OpenStack Cinder storage assets, OpenShift Container Platform installs the OpenStack Cinder CSI Driver Operator and the OpenStack Cinder CSI driver in the openshift-cluster-csi-drivers
namespace.
The OpenStack Cinder CSI Driver Operator provides a CSI storage class that you can use to create PVCs.
The OpenStack Cinder CSI driver enables you to create and mount OpenStack Cinder PVs.
OpenShift Container Platform provides automatic migration for the Cinder in-tree volume plugin to its equivalent CSI driver. For more information, see CSI automatic migration. |
Storage vendors have traditionally provided storage drivers as part of Kubernetes. With the implementation of the Container Storage Interface (CSI), third-party providers can instead deliver storage plugins using a standard interface without ever having to change the core Kubernetes code.
CSI Operators give OpenShift Container Platform users storage options, such as volume snapshots, that are not possible with in-tree volume plugins.
OpenShift Container Platform defaults to using an in-tree (non-CSI) plugin to provision Cinder storage. In future OpenShift Container Platform versions, volumes provisioned using existing in-tree plugins are planned for migration to their equivalent CSI driver. CSI automatic migration should be seamless. Migration does not change how you use all existing API objects, such as persistent volumes, persistent volume claims, and storage classes. For more information about migration, see CSI automatic migration. After full migration, in-tree plugins will eventually be removed in future versions of OpenShift Container Platform. |
The OpenStack Cinder CSI driver uses the cinder.csi.openstack.org
parameter key to support dynamic provisioning.
To enable OpenStack Cinder CSI provisioning in OpenShift Container Platform, it is recommended that you overwrite the default in-tree storage class with standard-csi
. Alternatively, you can create the persistent volume claim (PVC) and specify the storage class as "standard-csi".
In OpenShift Container Platform, the default storage class references the in-tree Cinder driver. However, with CSI automatic migration enabled, volumes created using the default storage class actually use the CSI driver.
Use the following steps to apply the standard-csi
storage class by overwriting the default in-tree storage class.
List the storage class:
$ oc get storageclass
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
standard(default) cinder.csi.openstack.org Delete WaitForFirstConsumer true 46h
standard-csi kubernetes.io/cinder Delete WaitForFirstConsumer true 46h
Change the value of the annotation storageclass.kubernetes.io/is-default-class
to false
for the default storage class, as shown in the following example:
$ oc patch storageclass standard -p '{"metadata": {"annotations": {"storageclass.kubernetes.io/is-default-class": "false"}}}'
Make another storage class the default by adding or modifying the annotation as storageclass.kubernetes.io/is-default-class=true
.
$ oc patch storageclass standard-csi -p '{"metadata": {"annotations": {"storageclass.kubernetes.io/is-default-class": "true"}}}'
Verify that the PVC is now referencing the CSI storage class by default:
$ oc get storageclass
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
standard kubernetes.io/cinder Delete WaitForFirstConsumer true 46h
standard-csi(default) cinder.csi.openstack.org Delete WaitForFirstConsumer true 46h
Optional: You can define a new PVC without having to specify the storage class:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: cinder-claim
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
A PVC that does not specify a specific storage class is automatically provisioned by using the default storage class.
Optional: After the new file has been configured, create it in your cluster:
$ oc create -f cinder-claim.yaml