MKS is part of the Morpheus hybrid cloud management and application infrastructure automation engine. Since MKS deploy upstream Kubernetes on industry standard Linux platforms, itโs easy for the users to customize and deploy the tools they need without worrying about compatibility.
HPE CSI Driver for Kubernetes is no exception to this rule as the CSI driver thrive on the same basic principles and customers may take advantage of HPE Alletra Storage MP B10000 with MKS today to deploy stateful workloads with little to no effort in a secure and reliable manner on their private clouds.
HPE CSI Driver for Kubernetes 2.5.2 brings many other important updates and improvements besides official MKS support โ and those include:
Ecosystem updates
Since the previous version of the CSI driver just missed Kubernetes 1.31 and 1.32 recently shipped, both releases are now officially supported. Since there were no breaking changes in either release, the previous version of the CSI driver worked out of the box. In a similar manner, Red Hat OpenShift 4.17 and 4.18 has now both been certified with the HPE CSI Operator for OpenShift.
Veeam Kasten provide data protection, disaster recovery and application mobility to workloads running on Kubernetes. In HPE CSI Driver for Kubernetes itโs now possible to backup VM workloads that using raw block devices. Veeam Kasten use snapshots and clones of the raw block devices to mount the filesystems hosted on the device to perform the necessary data management for data protection. In 2.5.2, the limitation that prevented cross volume mode access has been removed and validated with Veeam Kasten.
Performance and security improvements
Thereโs been several control plane performance enhancements and security hardening. The release notes hold all the line items but notable is that the HPE Alletra Storage MP B10000 Container Storage Provider (CSP) has improved locks and now prevents a rare duplicate VLUN creation occurrence found in high core count environments.
The improved lock also prevents the CSP from panicking in high churn situations where hundreds of outstanding requests are being serviced. Tangent to high utilization, the CSP is now able to create snapshots in arbitrary intervals as it was limited to once every second prior.
Efforts are ongoing to take better advantage of the improved control plane performance, and we now allow customers to manage the maximum number of volume attachments each node can have. The default limit is one hundred and the general recommendation is not to expand the limit unless itโs been tested in the particular environment as each situation is unique depending on active workloads and system resources.
Shortcomings in certain storage system APIs resorted in the CSP having to use alternative protocols against the storage system to perform certain operations. This resulted in elevated security concerns from customers urging a simpler model for communication between the Kubernetes cluster and the storage system. From HPE Primera onwards itโs now possible to opt-in for a more secure communication using only HTTPS on single well-known port. Details how to take advantage of this feature is now available on HPE Storage Container Orchestration Documentation (SCOD).
Enhanced serviceability
A few quality-of-life improvements also made it into this release. A very long overdue requested feature is the ability to expand the front end for NFS Server Provisioner Persistent Volume Claims. Prior to 2.5.2 users had to expand the backend volume manually which resulted in inaccurate space reporting and the operation was not user serviceable and had to be performed by a Kubernetes cluster administrator in the most common scenarios.
A popular pattern within enterprises is to map infrastructure resources to LDAP accounts for central management of authorization and authentication. Itโs now possible to use LDAP accounts with HPE Alletra Storage MP B10000 and prior platforms within the product family.
Users working with snapshots and clones daily sometimes need to logically remove parent volumes before the derived clones. This is a violation of the relationship from a storage system standpoint but as the CSI specification dictates, the clones should appear to the users as standalone entities. This relationship violation is now hidden from the Kubernetes control plane and users may now remove parent resources without consequence.
Other minor tweaks to Classic Peer Persistence include relaxed naming in Remote Copy Groups system names to allow disjointed naming conventions, which is common in the installed base.
Next steps for customers
Customers are encouraged to replace existing HPE CSI Driver installs to ensure theyโre taking advantage of the latest security enhancements and features. A platform update on HPE Alletra Storage MP B10000 10.4 had a breaking change for iSCSI target names which HPE CSI Driver 2.5.2 address.
- Review the HPE CSI Driver release notes on the GitHub project
- Explore the Helm chart on ArtifactHub
- Checkout the HPE CSI Operator in the Red Hat Ecosystem Catalog
- Ensure to follow up with the compatibility and support on SCOD
- Learn more about Morpheus Kubernetes Services
If you havenโt already, make sure to check out the HPE Developer Community at developer.hpe.com. They have an open Slack for customers and partners to engage with HPE. Sign up at developer.hpe.com/slack-signup.
Also make sure to keep tabs on Around the Storage Block for all future updates on HPE CSI Driver for Kubernetes.
MichaelMattsson
Data & Storage Nerd, Containers, DevOps, IT Automation
