Storage class improvements in Red Hat OpenShift 4.13
Here in this blog, we are going to learn about storage class improvements in Red Hat OpenShift 4.13. A crucial component of the Kubernetes storage user experience is storage classes. By exposing classes to users, they enable administrators to abstract storage usage and enable dynamic storage provisioning. Administrators can choose the type of storage they want to offer in this fashion, and users can select the best storage choice based on the needs of their individual applications.
This blog explains the specifics of the new functionality we’re introducing with OpenShift 4.13 regarding how storage classes are managed.
Manage the operator’s storage class creation
The Container Storage Interface (CSI) driver Operator automatically creates and maintains a default storage class for you when you install OpenShift on top of cloud service providers like AWS, Azure, or vSphere so that users are prepared to deploy stateful workloads without further administrative intervention.
This isn’t always the desired behavior, however. Some administrators advocate handling their own storage class management. We increase the flexibility in how operators control their storage classes in OpenShift 4.13. The following are the most common justifications for this use case:
- The storage type does not satisfy the technical or business requirements.
- Since administrators could desire to use the same default storage class name across environments, the storage class naming nomenclature is not compliant.
- In contexts with limited access, deactivate dynamic provisioning by removing the storage classes.
The new storage class states that you can set it with OpenShift 4.13 to define how operators should manage the storage classes.
Managed (Default): The CSI operator actively manages its default storage class, which means that in the event that an administrator tries to manually change or remove it, the default storage class is continually reconciled.
Unmanaged: The administrator can adjust the storage class to suit their needs by changing it. Storage class reconciliation is not being done by the CSI operator.
Removed: The default storage class is deleted by the CSI operator. The administrator must start over and build a new one.
So how does it function? You must update the ClusterCSIDriver object through the web UI or CLI and adjust the storageClassState parameter to one of the choices mentioned above in order to change the storage class policy.
List the storage classes before using the oc get command to make changes to the ClusterCSIDriver object.
$ oc get sc $ oc edit clustercsidriver <name_of_the_provisioner>
For instance, on a cluster installed by AWS, the process will resemble this:
$oc get sc oc get sc NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE gp2-csi ebs.csi.aws.com Delete WaitForFirstConsumer true 114m gp3-csi (default) ebs.csi.aws.com Delete WaitForFirstConsumer true 114m
Edit the ClusterCSIDriver object and set the storageClassState parameter in the spec section. The provisioner’s name is ebs.csi.aws.com.
# oc edit clustercsidriver ebs.csi.aws.com apiVersion: operator.openshift.io/v1 kind: ClusterCSIDriver metadata: name: ebs.csi.aws.com (...) spec: (...) storageClassState: Unmanaged # Add parameter here
The OpenShift EBS operator will not reconcile the changes if the storageClassState option is set to Unmanaged, allowing the administrator to alter the storage class as necessary in a secure manner.
The oc patch command enables you to accomplish the same task as well:
$ oc patch clustercsidriver ebs.csi.aws.com --type=merge -p "{\"spec\":{\"storageClassState\":\"Unmanaged\"”
The CSI drivers listed below enable this new feature:
- vSphere
- AWS EBS
- Azure Disk
- Azure File
- GCP PD
- IBM VPC Block
- AliCloud Disk
- RH-OSP Cinder
- Ovirt
Support for multiple default storage classes
A practical feature called default storage class applies a storage class to all PVs that don’t specifically set one in their PVC. Given that the names of the storage classes can vary throughout clusters, this can be quite advantageous for the mobility of workloads.
There could only be one default storage class defined per cluster prior to OpenShift 4.13. Any new PVC request would fail if several default storage classes were configured.
oc get sc NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE gp2-csi ebs.csi.aws.com Delete WaitForFirstConsumer true 161m gp3-csi (default) ebs.csi.aws.com Delete WaitForFirstConsumer true 161m gp3-test (default) ebs.csi.aws.com Delete WaitForFirstConsumer true 48s bash-4.4 ~ $ oc create -f pvc.yaml Error from server (Forbidden): error when creating "pvc.yaml": persistentvolumeclaims "pvc_test" is forbidden: Internal error occurred: 2 default StorageClasses were found
Multiple default classes shouldn’t exist in a cluster, but it is possible for this to occur in certain circumstances, such as when an administrator changes the default storage class and the cluster has two default classes for a brief period of time. We want to prevent as many user requests from failing as we can. The user experience changes when several default classes are found as of OpenShift 4.13.
The default storage class with the most recent metadata, if there are several default classes found. Use of metadata.creationTimestamp is planned. To put it another way, the most recent storage class will be employed. Instead of the time the storage class was set as the default, the cluster looks at the most recent time the storage class was created.
By reducing the number of user-facing mistakes, this new functionality promotes flexibility. However, a cluster shouldn’t have more than one default storage class; in that case, an alert is sent and the admin should still be informed.
Retro active storage class assignment (Tech Preview)
What occurs if the default storage class is not set? We already discussed how OpenShift manages various default storage classes. The PVC will currently remain in the pending state indefinitely, and users must delete and recreate it using an explicit storage class name.
The PVC will stay in the pending state thanks to this new functionality until a default storage class is created or one of the already-existing storage classes is made the default. The PVC will be retroactively allocated to the new default storage class as soon as it is designated as the default storage class.
This new behavior is beneficial in a variety of circumstances.
- Users won’t need to redo their PVs if administrators forget to specify a default storage class because it will be retroactively applied to pending PVs.
- When installing a cluster, components could ask for a PVC even though the storage operator hadn’t yet established a default storage class.
- For a brief moment after switching default storage classes, there is no default class in the cluster.
It’s important to note that this functionality is currently available only through a feature gate and as a Technology Preview. PVCs won’t be retrospectively allocated unless the TechPreviewNoUpgrade feature set is activated because the functionality is by default disabled.
We welcome everyone’s testing and input on this feature, however, if you choose to activate the TechPreviewNoUpgrade feature set, your cluster will no longer be upgradeable and all other Technology Preview features will become active.
To activate the TechPreviewNoUpgrade feature set, use the YAML format described below: