Managing the default storage class - Using Container Storage Interface (CSI) | Storage

Overview
Managing the default storage class using the web console
Managing the default storage class using the CLI
Absent or multiple default storage classes
- Multiple default storage classes
- Absent default storage class
Changing the default storage class

Overview

Managing the default storage class allows you to accomplish several different objectives:

Enforcing static provisioning by disabling dynamic provisioning.
When you have other preferred storage classes, preventing the storage operator from re-creating the initial default storage class.
Renaming, or otherwise changing, the default storage class

To accomplish these objectives, you change the setting for the spec.storageClassState field in the ClusterCSIDriver object. The possible settings for this field are:

Managed: (Default) The Container Storage Interface (CSI) operator is actively managing its default storage class, so that most manual changes made by a cluster administrator to the default storage class are removed, and the default storage class is continuously re-created if you attempt to manually delete it.
Unmanaged: You can modify the default storage class. The CSI operator is not actively managing storage classes, so that it is not reconciling the default storage class it creates automatically.
Removed: The CSI operators deletes the default storage class.

Managing the default storage classes is supported by the following Container Storage Interface (CSI) driver operators:

Managing the default storage class using the web console

Prerequisites

Access to the OpenShift Container Platform web console.
Access to the cluster with cluster-admin privileges.

Procedure

To manage the default storage class using the web console:

Log in to the web console.
Click Administration > CustomResourceDefinitions.
On the CustomResourceDefinitions page, type clustercsidriver to find the ClusterCSIDriver object.
Click ClusterCSIDriver, and then click the Instances tab.
Click the name of the desired instance, and then click the YAML tab.

Add the spec.storageClassState field with a value of Managed, Unmanaged, or Removed.

Example

...
spec:
  driverConfig:
    driverType: ''
  logLevel: Normal
  managementState: Managed
  observedConfig: null
  operatorLogLevel: Normal
  storageClassState: Unmanaged (1)
...

1	`spec.storageClassState` field set to "Unmanaged"

Click Save.

Managing the default storage class using the CLI

Prerequisites

Access to the cluster with cluster-admin privileges.

Procedure

To manage the storage class using the CLI, run the following command:

oc patch clustercsidriver $DRIVERNAME --type=merge -p "{\"spec\":{\"storageClassState\":\"${STATE}\"}}" (1)

1	Where `${STATE}` is "Removed" or "Managed" or "Unmanaged". Where `$DRIVERNAME` is the provisioner name. You can find the provisioner name by running the command `oc get sc`.

Absent or multiple default storage classes

Multiple default storage classes

Multiple default storage classes can occur if you mark a non-default storage class as default and do not unset the existing default storage class, or you create a default storage class when a default storage class is already present. With multiple default storage classes present, any persistent volume claim (PVC) requesting the default storage class (pvc.spec.storageClassName=nil) gets the most recently created default storage class, regardless of the default status of that storage class, and the administrator receives an alert in the alerts dashboard that there are multiple default storage classes, MultipleDefaultStorageClasses.

Absent default storage class

There are two possible scenarios where PVCs can attempt to use a non-existent default storage class:

An administrator removes the default storage class or marks it as non-default, and then a user creates a PVC requesting the default storage class.
During installation, the installer creates a PVC requesting the default storage class, which has not yet been created.

In the preceding scenarios, the PVCs remain in pending state indefinitely.

OpenShift Container Platform provides a feature to retroactively assign the default storage class to PVCs, so that they do not remain in the pending state. With this feature enabled, PVCs requesting the default storage class that are created when no default storage classes exists, remain in the pending state until a default storage class is created, or one of the existing storage classes is declared the default. As soon as the default storage class is created or declared, the PVC gets the new default storage class.

Retroactive default storage class assignment is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.

Procedure

To enable retroactive default storage class assignment:

Enable feature gates (see Nodes → Working with clusters → Enabling features using feature gates).

After turning on Technology Preview features using feature gates, they cannot be turned off. As a result, cluster upgrades are prevented.

The following configuration example enables retroactive default storage class assignment, and all other Technology Preview features:
```
apiVersion: config.openshift.io/v1
kind: FeatureGate
metadata:
  name: cluster
spec:
  featureSet: TechPreviewNoUpgrade (1)
...
```
1 Enables retroactive default storage class assignment.

Changing the default storage class

Use the following procedure to change the default storage class.

For example, if you have two defined storage classes, gp3 and standard, and you want to change the default storage class from gp3 to standard.

Prerequisites

Access to the cluster with cluster-admin privileges.

Procedure

To change the default storage class:

List the storage classes:

$ oc get storageclass

Example output

NAME                 TYPE
gp3 (default)        kubernetes.io/aws-ebs (1)
standard             kubernetes.io/aws-ebs

1	`(default)` indicates the default storage class.

Make the desired storage class the default.

For the desired storage class, set the storageclass.kubernetes.io/is-default-class annotation to true by running the following command:

$ oc patch storageclass standard -p '{"metadata": {"annotations": {"storageclass.kubernetes.io/is-default-class": "true"}}}'

You can have multiple default storage classes for a short time. However, you should ensure that only one default storage class exists eventually.

With multiple default storage classes present, any persistent volume claim (PVC) requesting the default storage class (pvc.spec.storageClassName=nil) gets the most recently created default storage class, regardless of the default status of that storage class, and the administrator receives an alert in the alerts dashboard that there are multiple default storage classes, MultipleDefaultStorageClasses.

Remove the default storage class setting from the old default storage class.

For the old default storage class, change the value of the storageclass.kubernetes.io/is-default-class annotation to false by running the following command:
```
$ oc patch storageclass gp3 -p '{"metadata": {"annotations": {"storageclass.kubernetes.io/is-default-class": "false"}}}'
```

Verify the changes:

$ oc get storageclass

Example output

NAME                 TYPE
gp3                  kubernetes.io/aws-ebs
standard (default)   kubernetes.io/aws-ebs