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:
- Install/upgrade Trident to v21.04.
- Define and create a
TridentBackendConfigobject 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.credentialsis a new field that references a pre-defined Kubernetes Secret containing access credentials for the backend.
spec.deletionPolicytakes one of two values: delete [to delete the Trident backend if the associated
TridentBackendConfigobject is deleted] or retain [deleting the
TridentBackendConfigdoes not delete the actual backend, but only the
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
TridentBackendConfig and not using
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:
- Liveness and Readiness probes are configured for Kubernetes 1.13 and above.
- 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 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
igroupNamefrom 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
igroupNamecan 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
- Volume labels no longer require virtual storage pools for all storage drivers.
- Control the visibility of the
.snapshotdirectory for ANF using the
snapshotDirparameter for the
- 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.