Around the Storage Block

HPE CSI Driver for Kubernetes and Red Hat OpenShift in beta


Historically, storage in Kubernetes has been a chore for vendors. In-tree (code that lives in the official GitHub repo of Kubernetes) drivers has long been closed to contribute due to its unmaintainable model. The in-tree FlexVolume plugin allowed vendors to write their own discrete drivers. The interface, management and delivery mechanism best-before-date have expired of the FlexVolume plugin. The Container Storage Interface (CSI) initiative started as a cross-technology concept between container orchestrators to solve the storage headache once and for all. It floated around as a Google doc before an initial specification got published on GitHub. CSI got promoted to GA in Kubernetes 1.13 released in January this year and we’re seeing downstream Kubernetes vendors starting to adopt CSI at a rapid pace. In this blog post we’ll preview the HPE CSI Driver for Red Hat OpenShift 4.1 with the HPE Nimble Storage Container Storage Provider (CSP).

Benefits of CSI

The core strength of CSI is the complete autonomy for the storage vendor to innovate at their own pace, give the user choice and radically simplify operations of the storage subsystem integration. Another key aspect of CSI is that it’s decoupled from core Kubernetes as CSI is an extension of Kubernetes and again increases the rate of innovation. A CSI driver may implement some or all the different capabilities CSI provides or provide their unique functionality. HPE has chosen to abstract the architecture even further by making the CSI driver multi-vendor capable, meaning that customers will be able to use the same driver with multiple HPE products. HPE Nimble Storage happens to be the first.



Another fundamental difference in functionality from the end-user perspective is the concept of treating data services as native objects in Kubernetes. For example, a snapshot on a HPE Nimble Storage array volume will appear in Kubernetes as a native API object that is referenceable from other objects to extend functionality, like creating a clone from a snapshot. Vendors also have the ability to add their own extensions that allow abstracting their storage systems to native Kubernetes API objects. This mechanism is called Custom Resource Definitions (CRD). The HPE CSI Driver contains one simple CRD to showcase this functionality, it enumerates storage related compute node information, such as IQNs, networks and/or WWPNs.

Here are the current features available in the CSI spec. The HPE Nimble Storage CSP supports all the capabilities out of the gate.



Note: In the demo below with Red Hat OpenShift 4.1, not all these APIs weren't available. Please see the the following blog post on the HPE DEV community.


Red Hat OpenShift 4.1 with CSI in Technology Preview

Red Hat matures upstream features in OpenShift at their own pace. CSI has been in Technology Preview for a few releases and is expected to hit GA in OpenShift 4.2 so we captured a great opportunity to showcase the HPE CSI Driver with OpenShift 4.1.

We put together a demo to illustrate a handful of the CSI features available in OpenShift to get an idea of what the end-user experience will look like.

Note: All the workload definitions used in the demo are available in this GitHub repo.

Not all of the CSI featues are available in Red Hat OpenShift 4.1, for a more comprehensive demo (and some additional background on the project) please see this blog post on the HPE DEV community.

The supported delivery mechanism of a CSI driver in Red Hat OpenShift 4.2 will be through the Kubernetes Operator model. In time for GA, an Operator will be available for the HPE CSI Driver for Kubernetes to be deployed through the Operator Hub.

HPE CSI Driver for Kubernetes availability

All components needed to deploy and use the HPE CSI Driver for Kubernetes and surrounding components is available as Open Source under the Apache 2.0 license on GitHub. We do not recommend using this software for any production workloads and we do not provide official support through HPE during the beta. All correspondence must go through the GitHub issue tracker or feel free to discuss any issues you may have in the #NimbleStorage channel by joining the HPE DEV slack community. We’ll announce the product GA through regular HPE channels in the fall.


It’s a safe bet today to select a vendor with a long track record in the Kubernetes community that promotes openness yet able to provide enterprise-level support. All the business logic for the HPE Nimble Storage Container Storage Provider (CSP) has been reused and provide the same rich data service interface as previous integrations, such as Docker and the FlexVolume driver. Feature parity, stability and serviceability are a few of the cornerstone pillars engineering have stood on to deliver a best in class experience for our customers. Expect more HPE storage products to have full integration with the HPE CSI Driver for Kubernetes in the not too distant future so stay tuned for more updates on this exciting development!

Foot note: The HPE Nimble Kube Storage Controller and FlexVolume driver is still the supported solution for Kubernetes and OpenShift.

About the Author


Data & Storage Nerd, Containers, DevOps, IT Automation