As Hewlett Packard Enterprise continue to expand into the containerized application space with the recent announcement of the HPE Container Platform there is no slowing down on the HPE primary storage front. This week HPE made the HPE CSI Driver for Kubernetes 1.1.0 Generally Available (GA). For an introduction to the HPE CSI Driver for Kubernetes, visit the 1.0.0 release blog.
This release introduces broader ecosystem support and closer conformance to the CSI specification with a few more features labelled production ready. But first, letโs revisit the HPE CSI Driver for Kubernetes architecture.
Architecture
Itโs been clear from the start the HPE CSI Driver for Kubernetes is a multi-platform and multi-vendor CSI driver. HPE takes care of all the complexities of CSI, Kubernetes and attaching/detatching storage to a node. This is primarily an effort to avoid duplicate work between teams at HPE. The primary storage portfolio has many block based storage platforms which all have host commonalities such as discovering LUNs, formatting filesystems, setting up multi-pathing correctly and so forth. Ideally, teams should focus on making sure the right platform features gets abstracted through the provisioner and all the right backend APIs are exercised properly. This component is called a Container Storage Provider (CSP) and is a unique piece of software that anyone can implement as itโs an open API specification.
The only platform that is supported (as of the date this blog is written) by the CSI driver is HPE Nimble Storage. The team is bombarded with questions when there will be a CSI driver for HPE 3PAR/Primera and HPE Cloud Volumes. If youโve paid attention, there will not be a CSI driver for any platform other HPE primary storage platform. There will be a CSP for HPE 3PAR/Primera coming out next (very soon!) and later this year, a CSP for HPE Cloud Volumes.
New features
While snapshots, clones and volume expansion were part of our beta program of the HPE CSI Driver for Kubernetes, those features were not well tested and deemed production ready until version 1.1.0. The legacy HPE container integrations have always been capable of creating snapshots and clones, the difference with CSI is that these constructs are now first class citizens in Kubernetes and allows end users to be self-sufficient with their Persistent Volume Claims in a platform agnostic way.
Another sought after feature is the ability to allow users to expand their Persistent Volume Claims. This is a very common "Day 2โ operation that use to be an extremely high touch and tedious operation before this feature was made available through CSI. This capability is now GAโd in the HPE CSI Driver for Kubernetes.
Refer to the following table for a comprehensive overview of feature parity and maturity.
If youโre interested in how any of these new workflows are wired, head over to the HPE DEV community as we walk through a few common examples and use cases.
Delivery vehicles
This release introduces a few more and updated delivery vehicles. HPE recognizes users wants choice and itโs important to provide the mainstream ways of deploying applications on Kubernetes. As a recap, the HPE CSI Driver for Kubernetes is deployed like any other application on your Kubernetes cluster. For a no frills deployment there are workload declarations available in plain YAML in the GitHub repository for each different version of Kubernetes.
The most common pattern to deploy applications on Kubernetes is using Helm. The previous version of the CSI driver only supports Helm 2. The new version supports both Helm 2 and Helm 3. There are many distinct advantages to use Helm 3 as it removes the need to have a privileged deployment (Tiller) running in the clusters and as long as you have access to a namespace, applications may be deployed with Helm 3. The Helm chart (package format for Helm) is available on hub.helm.sh.
In this release HPE also introduces an Operator LifeCycle Manager (OLM) for the HPE CSI Driver for Kubernetes dubbed the HPE CSI Operator for Kubernetes (still in beta!). This allows a Kubernetes administrator to manage the CSI driver like a single entity without actually knowing that itโs in fact a Deployment, DaemonSet and a bunch of Custom Resource Definitions (CRDs) along with a set of RBAC declarations. It radically simplifies upgrades and day 2 management of Kubernetes applications. This topic will be covered more in depth in a future blog post on HPE Storage Tech Insiders!
Expanded ecosystem support
As HPE continue to gain momentum with the HPE Container Platform the need for supporting customers with our partner solutions is imperative. With the introduction of the HPE CSI Operator for Kubernetes we introduce Red Hat CoreOS as a supported operating system along with official support for Red Hat OpenShift 4. Customers are encouraged to participate in the beta program with the HPE CSI Operator for Kubernetes, stay tuned for a separate release blog that extends our capabilities to Red Hat OpenShift.
Next steps
Stay in touch with the team on the official Slack community for developers, architects and IT Ops leveraging HPE storage products with Kubernetes. Sign up on slack.hpedev.io.
MichaelMattsson
Data & Storage Nerd, Containers, DevOps, IT Automation
