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
  name: basic
provisioner: netapp.io/trident
  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: myFavoriteAff:.*
  • I want every pool named "bronze": .*:bronze
  • I want every pool with the phrase "gold" in it, that also comes from a backend with "ssd" in the name: .*ssd.*:.*gold.*

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
  name: allButThese
provisioner: netapp.io/trident
  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!

Those three things aren’t all we’ve been up to! I talked about liveness probes and simplified deployment when using a non-default registry in the beta announcement, but there’s a lot more too:

  • 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 tridentctl to get the logs from the last instance to help with troubleshooting.

The future is now!

We can't encourage you enough to upgrade to Trident 18.07 as soon as you can to take advantage of all the other bug fixes and improvements which I haven’t listed here.

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!

If you have any questions, concerns, or issues, please reach out to us in the comments below, using our Slack team, or via GitHub issues.

About Andrew Sullivan

Andrew has worked in the information technology industry for over 10 years, with a rich history of database development, DevOps experience, and virtualization. He is currently focused on storage and virtualization automation, and driving simplicity into everyday workflows.

Pin It on Pinterest