Trident v21.04 is GA today. Here’s the breakdown of all the features and improvements available with the latest release:

 

Create and manage Trident backends with kubectl

 

You can now manage Trident backends directly through the Kubernetes interface using command-line tools such as kubectl/oc. This is achieved with a new Custom Resource Definition (CRD) that will hereafter be used to represent backend configurations provided to Trident by the Kubernetes admin called TridentBackendConfig. You can now handle end-to-end management of Trident declaratively through Kubernetes including deployment of the Trident operator, installation of Trident (create a TridentOrchestrator), backend creations (using TridentBackendConfigs), and updates of Trident or any of the backends, all through YAML manifests in Kubernetes.

 

The sequence of steps will look something like this:

  1. Install/upgrade Trident to v21.04.
  2. Define and create a TridentBackendConfig object for a new backend. Sample manifests can be found here. Backend-specific parameters are all detailed in the Backend Configuration section of our documentation.

 

TridentBackendConfig objects also introduce a couple of differences: 

  • spec.credentials is a new field that references a pre-defined Kubernetes Secret containing access credentials for the backend.
  • spec.deletionPolicy takes one of two values: delete [to delete the Trident backend if the associated TridentBackendConfig object is deleted] or retain [deleting the TridentBackendConfig does not delete the actual backend, but only the TridentBackendConfig object].
What happens to existing backends?

 

Backends created with tridentctl will continue to remain operational throughout the upgrade. You can also create a TridentBackendConfig to manage pre-existing backends using kubectl if you so desire. This can be achieved by creating a TridentBackendConfig object that is identical to the existing backend (i.e., all config options used on the backend [including backendName] must be set in the spec of the TridentBackendConfig object). Trident will automatically bind the newly created TridentBackendConfig to the existing backend. Keep in mind that this should be done only when it is desired to manage legacy backends through kubectl with TridentBackendConfig and not using tridentctl.

 

You can learn more about backend management options and how they work from the documentation.

 

Trident Health Probes

 

To help Kubernetes SREs monitor Trident’s health and state, v21.04 introduces Liveness, Readiness, and Startup probes. No matter how you choose to install Trident (tridentctl, Helm chart, Operator), Trident’s health probes are defined in Trident’s controller deployment and DaemonSet (both named trident-csi). Depending on the Kubernetes version used:

 

  1. Liveness and Readiness probes are configured for Kubernetes 1.13 and above.
  2. Startup probe is configured for Kubernetes 1.18 and above.

 

The probes help ensure Trident’s availability and enable Kubernetes to proactively handle situations where Trident isn’t running/starting up.

 

List Trident’s image dependencies with tridentctl

 

A constant question we hear from our users is: How can I obtain the list of container images required for installing Trident? Well, fear no more! tridentctl images now provides all container images needed for a given Kubernetes version. This command does not require access to a Kubernetes cluster or a KUBECONFIG file. Download tridentctl, run tridentctl images -v <kubernetes-semantic-version>(tridentctl images -v v1.19.8 for example), and there you go!

 

igroups with the ONTAP-SAN drivers

 

In accordance with Trident’s recommended best practice of maintaining unique igroups for each Trident install, v21.04 now automatically creates an igroup on the SVM if no igroupName is defined in the backend. For all backends (new and pre-existing) that use the ontap-san or ontap-san-economy drivers:

  • Omitting igroupName from the backend definition will result in Trident creating a trident-<backend-UUID> igroup on the SVM used. This will also apply to existing backends that are updated to have igroupName removed.
  • Alternatively, igroupName can be defined to point to a pre-existing igroup that is created on the SVM. Trident shall make use of the igroup referenced and it is the administrator’s responsibility to ensure the igroup is not being used in other Trident installs.

 

That’s not all

 

There are several other enhancements!

  • Shared VPC support on GCP with the cvs-gcp driver.
  • Volume labels no longer require virtual storage pools for all storage drivers.
  • Control the visibility of the .snapshot directory for ANF using the snapshotDir parameter for the azure-netapp-files driver.
  • Recreate strategy for the Trident operator.
  • 300 GiB minimum volume size support for default CVS service type on GCP. Subscribe for sub-1TiB volumes today!

 

For a complete list of all bug fixes and issues resolved, check out the Release Notes.

Get in touch with us! Join the Slack workspace

Visit netapp.io/slack and hang out with us in the #containers channel.

Bala RameshBabu
Bala is a Technical Marketing Engineer who focuses on Trident, NetApp's dynamic storage provisioner for Kubernetes and Docker. With a background in OpenStack, he focuses on open-source solutions and DevOps workflows. When not at work, you can find him in a soccer field or reading biographies

Pin It on Pinterest