In the Kubernetes and OpenShift ecosystem, you can think of a StorageClass as a blueprint for a house. It defines exactly how a volume is built and its initial characteristics. Historically, once a PersistentVolumeClaim (PVC) was live, tweaking performance metrics like input/output operations per second (IOPS) or throughput was a manual and often disruptive process. Upgrading storage usually required tearing down the volume, recreating it, or performing complex snapshot migrations.
The VolumeAttributesClass (VAC), introduced in Red Hat OpenShift 4.21 as fully supported, offers a modern approach by making volume updates as smooth as initial provisioning.
The key difference between a StorageClass and a VolumeAttributesClass lies in the life cycle:
StorageClass(provisioning): Defines how a new volume is provisioned. Once the PVC is live, thestorageClassNameis immutable.VolumeAttributesClass(modification): Defines how an existing volume’s attributes can be modified. Unlike aStorageClass, thevolumeAttributesClassNameon a PVC is mutable and can be modified at any time.- While a
StorageClassserves as the architectural blueprint for a volume, aVolumeAttributesClassacts as a renovation plan, allowing for utility upgrades without requiring you to move data or services.
Hands-on demo: Modifying a live volume without downtime
In this demo, we will use the AWS EBS CSI driver to switch a volume from a standard performance tier to a high performance tier while a pod is actively writing to it.
Prerequisites
- An OpenShift cluster (4.21 or later).
- Supported CSI driver: A driver that supports the ModifyVolume capability.
- AWS: EBS CSI driver v1.35.0+.
- Google Cloud Platform: PD CSI driver (requires C3 or N4 instances; the default E2 cluster types do not support Hyperdisk VAC).
- Third-party vendors: For CSI drivers not shipped with OpenShift, consult your storage vendor to confirm support for the
VolumeAttributesClassfeature.
1. Define the performance tiers
First, we’ll create two VolumeAttributesClass objects. These do not create storage themselves; they define the parameters for modification.
Standard performance (Base IOPS)
Navigate to Storage → VolumeAttributesClasses and click Create VolumeAttributesClass. Update the sample manifest with the following properties, as shown in Figure 1:
name: base-iops-example
driverName: ebs.csi.aws.com
parameters:
type: gp3
iops: "3000"
throughput: "125"
Figure 2 shows the result.
High performance
Repeat the previous steps using the following specific values to create the high-performance VAC:
name: high-iops-example
driverName: ebs.csi.aws.com
parameters:
type: gp3
iops: "5000"
throughput: "125"2. Create a Volume
Create a PVC, referencing your StorageClass and the base-iops-example VAC as the starting baseline. Complete the form (Figure 3) and click Submit.
Storage volumes often wait for the first consumer (Pod) to be bound. To move the process forward, create a Deployment that references this PVC.
As shown in Figure 5, the transition is complete. The PVC status has moved from Pending to Bound. The volume is now actively attached to the running pod within our Deployment. Additionally, because the base-iops-example was referenced during PVC creation, the VolumeAttributesClass is already applied as the performance baseline, which is 3,000 IOPS.
3. The magic moment: Modifying the PVC without downtime
You can upgrade the underlying performance of the volume and shift from the standard baseline to the high-performance tier without a single second of downtime. In the past, this would have required a maintenance window and a pod restart. With the VolumeAttributesClass, it is as simple as updating a reference.
Steps to upgrade performance
To trigger the modification, simply point the PVC to the high-iops-example VAC:
- Navigate to the PersistentVolumeClaim details page.
- Open the Actions menu (top right) and select Modify VolumeAttributesClass.
- Choose the new tier: Select high-iops-example from the drop-down menu (Figure 6) and click Save. This triggers the OpenShift reconciliation logic to communicate with the cloud provider (Figure 7).
Figure 8 shows the successful update.
What happens behind the scenes?
Unlike a StorageClass, the VolumeAttributesClass is mutable. OpenShift immediately begins the reconciliation. While the cloud provider modifies the volume in the background, the Pod continues to read and write data normally. During this transition, note that parameters are "sticky." If you switch to a new VolumeAttributesClass, any attributes not explicitly defined in the new class will retain their previous values rather than reverting to a driver default.
To ensure visibility into this process, OpenShift provides a specialized alert that identifies drivers with mismatching VAC attributes. This helps you quickly detect when a volume's physical state has drifted from its intended configuration or if a reconciliation is inconsistent.
OpenShift handles the transition through three primary states:
- Scenario 1: The "in progress" state: The CSI driver and cloud provider (for example, AWS) are executing the modification. An alert appears in the UI: "Waiting for VolumeAttributesClass modification..." The application remains fully operational.
- Scenario 2: The "error" state: If the modification fails (for example, due to invalid provider limits), an error alert is displayed. Crucially, the volume continues to operate using its last known good configuration, ensuring the data is never at risk.
- Scenario 3: The "success" state: Once the provider confirms the change, the UI reflects the new VAC. At this point, the underlying storage hardware has successfully adjusted its parameters. Whether the volume was scaled up for a performance spike or optimized for cost, the application immediately benefits from the updated performance characteristics (such as increased IOPS or throughput).
Cloud provider cooldown periods
While the VolumeAttributesClass makes the request to change performance instantaneous from an OpenShift perspective, the underlying cloud infrastructure (like Amazon EBS or Google Cloud Platform Persistent Disks) often enforces a "cooldown period" between modifications.
For example, AWS EBS volumes typically allow only one modification every six hours. If you attempt to switch from base-iops-example to high-iops-example and then immediately try to switch back, the second request might stay in the In Progress state for a significant amount of time or return a provider-side error until that window has passed.
Conclusion
With the introduction of VolumeAttributesClass, OpenShift 4.21+ enables an elastic approach to persistent storage. By eliminating disruptive maintenance windows, you can now scale IOPS and throughput on demand to meet fluctuating traffic spikes or optimize infrastructure costs.
The integration of VolumeAttributesClass within the OpenShift ensures that managing the data layer is as flexible as managing application pods. This allows the storage infrastructure to keep pace with the evolving demands of a modern production environment, ensuring high performance without sacrificing application availability.
Learn more:
