OpenStack Cinder CSI Driver Operator

Overview

OKD 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, OKD 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.

About CSI

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 plug-ins using a standard interface without ever having to change the core Kubernetes code.

CSI Operators give OKD users storage options, such as volume snapshots, that are not possible with in-tree volume plug-ins.

Making OpenStack Cinder CSI the default storage class

In OKD, the default storage class references the in-tree Cinder driver. The storage class will default to referencing OpenStack Cinder CSI in a subsequent update of OKD. Volumes provisioned using the existing in-tree storage class are planned for migration to the OpenStack Cinder CSI storage class at that time.

The OpenStack Cinder CSI driver uses the cinder.csi.openstack.org parameter key to support dynamic provisioning.

To enable OpenStack Cinder CSI provisioning in OKD, 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”.

Recommended procedure

Use the following steps to apply the standard-csi storage class by overwriting the default in-tree storage class.

  1. List the storage class:

    1. $ oc get storageclass

    Example output

    1. NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
    2. standard(default) cinder.csi.openstack.org Delete WaitForFirstConsumer true 46h
    3. standard-csi kubernetes.io/cinder Delete WaitForFirstConsumer true 46h
  2. 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:

    1. $ oc patch storageclass standard -p '{"metadata": {"annotations": {"storageclass.kubernetes.io/is-default-class": "false"}}}'
  3. Make another storage class the default by adding or modifying the annotation as storageclass.kubernetes.io/is-default-class=true.

    1. $ oc patch storageclass standard-csi -p '{"metadata": {"annotations": {"storageclass.kubernetes.io/is-default-class": "true"}}}'
  4. Verify that the PVC is now referencing the CSI storage class by default:

    1. $ oc get storageclass

    Example output

    1. NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
    2. standard kubernetes.io/cinder Delete WaitForFirstConsumer true 46h
    3. standard-csi(default) cinder.csi.openstack.org Delete WaitForFirstConsumer true 46h
  5. Optional: You can define a new PVC without having to specify the storage class:

    1. apiVersion: v1
    2. kind: PersistentVolumeClaim
    3. metadata:
    4. name: cinder-claim
    5. spec:
    6. accessModes:
    7. - ReadWriteOnce
    8. resources:
    9. requests:
    10. storage: 1Gi

    A PVC that does not specify a specific storage class is automatically provisioned by using the default storage class.

  6. Optional: After the new file has been configured, create it in your cluster:

    1. $ oc create -f cinder-claim.yaml

Additional resources