Is it August already? Time flies when you are having fun! The Trident team has been hard at work this summer to deliver some great new features in the 19.07 version of Trident, which is now available! Here’s the lowdown on what’s new with Trident 19.07.
Azure NetApp Files (ANF) for Trident
19.07 introduces support for the Azure NetApp Files service! Azure NetApp Files (ANF) is an enterprise class file service that is natively available on Azure. It provides a fully managed NFS service which offers consistently high performance, cloning, data protection in multiple service levels. ANF supports business workloads with high throughput and low latencies. The
azure-netapp-files driver in Trident will be used to work with ANF backends.
To get started with ANF for Trident, head on over to the ANF section of Trident’s docs.
Trident as an enhanced CSI provisioner
Exactly a year ago, Trident provided a preview version of its CSI driver as part of the 18.07 release. What a difference a year makes. Today, Trident’s enhanced CSI provisioner fully conforms to the CSI 1.1 specification and is suitable for production grade workloads. CSI was designed to provide a standard mechanism to expose storage to Kubernetes without “ever having to touch the core Kubernetes code”. All features provided by Trident will be available and this mode of operation works across all NetApp storage backends that Trident supports. For Kubernetes releases
1.14 and above, this is the default way of setting up Trident.
Jacob’s blog [written as part of the 19.07 Alpha release] encompasses the changes that have been introduced. The Trident documentation contains helpful links for deploying and upgrading an existing deployment.
On-demand volume snapshots
With on-demand snapshot support, users can regularly create backups of their volumes. Volumes can also be created from these snapshots. This feature is offered by Trident’s enriched CSI provisioner and requires some feature gates that need to be enabled, all of which is documented in Trident’s docs.
This section of the documentation goes over a simple workflow of creating snapshots and creating PVs from snapshots.
CRDs replace Trident’s etcd for maintaining Trident’s state
Trident will no longer need its own etcd for storing information. Instead, Custom Resources will be defined on the Kubernetes cluster to store Trident’s metadata. Trident introduces a set of Custom Resource Definitions (CRDs) that will maintain Trident’s stateful information with respect to backends, volumes, storage classes and so on. This eliminates Trident’s requirement for a dedicated PV on a NetApp backend to store its own metadata. Upgrading to Trident 19.07 will copy Trident’s metadata from its etcd [used by the previous release] and create associated CRD objects. Be sure to check out this blog on CRDs that Trident will use moving forward.
Virtual Storage Pools for Element and E-Series
Virtual Storage Pools are now supported for Element (HCI/SolidFire) and E-Series backends. Using Virtual Storage Pools helps to group resources in a backend-agnostic manner and provides greater flexibility to define multiple classes of service. You can specify parameters such as performance levels and QoS specifications and create multiple virtual storage pools which map to the same backend. These pools can be associated to Storage Classes by using a combination of selectors. This way, Trident abstracts the complexity of scheduling volumes on the backend and aggregates volumes of a similar performance type onto a virtual pool.
The Backend Configuration section of the Trident docs contains examples for configuring virtual pools.
That’s not all!
There are also some additional enhancements included:
- Space-allocation can be toggled for ONTAP SAN backends. The
spaceAllocationparameter can be defined for
ontap-sanbackends to control thin provisioning of LUNs.
- Kubernetes 1.15 support.
- Bugfixes and Improvements.