Well, well, well. It seems like it was just yesterday that we were launching 18.04, but it’s been three very quick months, Summer is in full swing, and 18.07 is here! The heat and humidity outside means that we’ve been hiding in the air conditioning, toiling over a hot keyboard, to bring you some amazing new features for Trident. Without further fanfare, let’s look at what’s new and exciting:
Container Storage Interface (CSI) alpha driver
If you missed the announcement from the beta, we have added an alpha driver that works with Kubernetes’ beta CSI integration. There’s some important things to know about CSI and NetApp’s integration, so be sure to check out the resources below, then go give it a try:
CSI is exciting and something we’re looking forward to in the future, be sure to see the video of it in action below:
Advanced storage pool matching
When a storage array is added as a backend, Trident evaluates the available resources and places them into storage pools. The attributes requested in the Kubernetes storage class are then matched against the storage pool properties, resulting in Trident being able to provision storage across new devices dynamically, with no intervention from the administrator.
However, sometimes we just want to specify the name of a pool, or pools, because we know the underlying characteristics are exactly what’s desired. To enable this, Trident has always supported the concept of specifying exactly which storage pools you want to use for a particular storage class. Historically, this meant having to provide a list of pools using a format like this:
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: basic provisioner: netapp.io/trident parameters: storagePools: "backendName:pool1,pool2"
Thanks to some hard work leading up to this release, we can now use regular expressions to provide patterns for desired storage pools!
Let’s look at some examples:
- I want every storage pool for a particular ONTAP backend:
- I want every pool named “bronze”:
- I want every pool with the phrase “gold” in it, that also comes from a backend with “ssd” in the name:
This gives considerable power and flexibility when creating storage classes to ensure that only the correct backends are used for your applications. To take things a step further, we also added the option to exclude storage pools too! This is super useful when you want to provide storage characteristics which may accidentally match resources you don’t want. Let’s look at an example:
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: allButThese provisioner: netapp.io/trident parameters: media: "ssd" excludeStoragePools: ".*SolidFire.*:cardboard"
Here we are generically selecting any flash backend, however using the
excludeStoragePools parameter we can specify that we don’t want to use the “
cardboard” QoS policy from any backend with “
SolidFire” in the name.
FlexGroup driver for ONTAP
Are you familiar with FlexGroups? In a nutshell, FlexGroups are one or more FlexVolumes that are treated as a single volume. ONTAP manages distributing workload across all constituent volumes, resulting in greater scalability and performance (up to 20PB in one “volume”!).
FlexGroups are phenomenal for some workloads, in particular anything that has lots of small-ish files and/or lots of metadata operations, like software builds, Big Data and AI/ML. To help even better enable those workloads in containers, Trident can now provision and manage FlexGroup-based PVs!
We have also verified that Trident works with the NVIDIA GPU Cloud using both Docker and Kubernetes, so if you have some machine learning, deep learning, or artificial intelligence workloads, then Trident is ready and able to manage all of your storage!
As always… So. Much. More!
- Updating etcd to 3.2.19 – etcd is a core component of Trident, providing a place to store the meta data vital to operation. Trident 18.07 updates etcd to version 3.2.19 which fixes many bugs and improves stability, however be aware that once etcd has been updated, it cannot be reverted to an earlier version.
- No snapshot policy means no snap reserve – previously, all volumes were created with a five percent snap reserve, this change removes the reserve on new volumes if the snapshot policy is set to “none” (the default).
- Provide all iSCSI LIFs in PV definition – for ONTAP iSCSI volumes, Trident will now include all of the iSCSI LIFs in the PV definition, giving the iSCSI client the ability to select from more than one target to connect to the cluster. This change does not affect SolidFire or E-Series.
- Added a “
--previous” switch to tridentctl – Kubernetes will keep logs for previous instantiations of a pod, this switch, when provided, will cause
tridentctlto get the logs from the last instance to help with troubleshooting.
The future is now!
Fall will be upon us seemingly tomorrow and NetApp Insight will be at the top of everyone’s mind. The preliminary list of sessions has been (secretly) passed around, and I have some great news: thePub and our technologies will be well represented!