Beginning with the 24.02 release, Trident is released every four months: February, June, and October.

Trident usually does not support alpha features in Kubernetes. Trident might support beta features within the two Trident releases that follow the Kubernetes beta release.

Trident does not have any dependencies on other NetApp software products and it works as a standalone application. However, you should have a NetApp backend storage device.

Use the tridentctl get command to obtain more information about your Trident configuration.

Yes. Prometheus endpoints that can be used to gather information about Trident operation, such as the number of backends managed, the number of volumes provisioned, bytes consumed, and so on. You can also use Cloud Insights for monitoring and analysis.

No. There are no changes as far as the user experience and functionalities are concerned. The provisioner name used is csi.trident.netapp.io. This method of installing Trident is recommended if you want to use all the new features provided by current and future releases.

Yes, Trident can be installed offline. Refer to Learn about Trident installation.

Yes. Trident 18.10 and later support remote installation capability from any machine that has kubectl access to the cluster. After kubectl access is verified (for example, initiate a kubectl get nodes command from the remote machine to verify), follow the installation instructions.

Trident is installed as a Kubernetes Deployment (ReplicaSet) with one instance, and so it has HA built in. You should not increase the number of replicas in the deployment. If the node where Trident is installed is lost or the pod is otherwise inaccessible, Kubernetes automatically re-deploys the pod to a healthy node in your cluster. Trident is control-plane only, so currently mounted pods are not affected if Trident is re-deployed.

Trident reads from the Kubernetes API Server to determine when applications request new PVCs, so it needs access to kube-system.

The Trident installer creates a Kubernetes ClusterRole, which has specific access to the cluster's PersistentVolume, PersistentVolumeClaim, StorageClass, and Secret resources of the Kubernetes cluster. Refer to Customize tridentctl installation.

You can locally generate and modify the exact manifest files Trident uses for installation, if needed. Refer to Customize tridentctl installation.

Although it is not advised, you can use the same backend SVM for two Trident instances. Specify a unique volume name for each instance during installation and/or specify a unique StoragePrefix parameter in the setup/backend.json file. This is to ensure the same FlexVol is not used for both instances.

Trident is simply a Kubernetes pod and can be installed wherever Kubernetes is running.

Yes, Trident is supported on AWS, Google Cloud, and Azure.

Yes, Trident supports the Azure NetApp Files service in Azure as well as the Cloud Volumes Service in GCP.

Although Trident is open source and provided for free, NetApp fully supports it provided your NetApp backend is supported.

To raise a support case, do one of the following:

You can create a support bundle by running tridentctl logs -a. In addition to the logs captured in the bundle, capture the kubelet log to diagnose the mount problems on the Kubernetes side. The instructions to get the kubelet log varies based on how Kubernetes is installed.

Create an issue on Trident Github and mention RFE in the subject and description of the issue.

Create an issue on Trident Github. Make sure to include all the necessary information and logs pertaining to the issue.

If you have any questions, issues, or requests, reach out to us through our Trident Discord channel or GitHub.

Update the backend's password with tridentctl update backend myBackend -f </path/to_new_backend.json> -n trident. Replace myBackend in the example with your backend name, and `/path/to_new_backend.json with the path to the correct backend.json file.

There are two likely scenarios why Trident cannot find a Kubernetes node. It can be because of a networking issue within Kubernetes or a DNS issue. The Trident node daemonset that runs on each Kubernetes node must be able to communicate with the Trident controller to register the node with Trident. If networking changes occurred after Trident was installed, you encounter this problem only with new Kubernetes nodes that are added to the cluster.

Data will not be lost if the Trident pod is destroyed. Trident metadata is stored in CRD objects. All PVs that have been provisioned by Trident will function normally.

NetApp supports upgrading Trident from one major release to the next immediate major release. You can upgrade from version 18.xx to 19.xx, 19.xx to 20.xx, and so on. You should test upgrading in a lab before production deployment.

If you need a fix for bugs observed after an upgrade, dependency issues, or an unsuccessful or incomplete upgrade, you should uninstall Trident and reinstall the earlier version using the specific instructions for that version. This is the only recommended way to downgrade to an earlier version.

The management LIF is mandatory. Data LIF varies:

Yes. Trident supports bidirectional CHAP for ONTAP backends. This requires setting useCHAP=true in your backend configuration.

Trident can dynamically create and manage export policies from version 20.04 onwards. This enables the storage administrator to provide one or more CIDR blocks in their backend configuration and have Trident add node IPs that fall within these ranges to an export policy it creates. In this manner, Trident automatically manages the addition and deletion of rules for nodes with IPs within the given CIDRs.

Trident supports defining IPv6 addresses for:

Trident must be installed using the flag --use-ipv6 (for tridentctl installation), IPv6 (for Trident operator), or tridentTPv6 (for Helm installation) for it to function over IPv6.

Yes, it is possible to update the backend Management LIF using the tridentctl update backend command.

You can update the Data LIF on ontap-nas and ontap-nas-economy only.

Trident can support many backends simultaneously, either with the same driver or different drivers.

Trident stores the backend credentials as Kubernetes Secrets.

If the backend attributes cannot be used to automatically select the right pools for a class, the storagePools and additionalStoragePools parameters are used to select a specific set of pools.

The excludeStoragePools parameter is used to filter the set of pools that Trident uses for provisioning and will remove any pools that match.

If there are multiple configured backends of the same type, Trident selects the appropriate backend based on the parameters present in StorageClass and PersistentVolumeClaim. For example, if there are multiple ontap-nas driver backends, Trident tries to match parameters in the StorageClass and PersistentVolumeClaim combined and match a backend which can deliver the requirements listed in StorageClass and PersistentVolumeClaim. If there are multiple backends that match the request, Trident selects from one of them at random.

Yes.

The ontap-nas-economy driver creates up to 200 Qtrees in the same FlexVol (configurable between 50 and 300), 100,000 Qtrees per cluster node, and 2.4M per cluster. When you enter a new PersistentVolumeClaim that is serviced by the economy driver, the driver looks to see if a FlexVol already exists that can service the new Qtree. If the FlexVol does not exist that can service the Qtree, a new FlexVol is created.

You can set Unix permissions on the volume provisioned by Trident by setting a parameter in the backend definition file.

By default, Trident does not set mount options to any value with Kubernetes. To specify the mount options in the Kubernetes Storage Class, follow the example given here.

To allow the appropriate hosts access to a volume, use the exportPolicy parameter configured in the backend definition file.

You can set encryption on the volume provisioned by Trident by using the encryption parameter in the backend definition file. For more information, refer to: How Trident works with NVE and NAE

Use StorageClasses to implement QoS for ONTAP.

The ONTAP drivers support either thin or thick provisioning. The ONTAP drivers default to thin provisioning. If thick provisioning is desired, you should configure either the backend definition file or the StorageClass. If both are configured, StorageClass takes precedence. Configure the following for ONTAP:

PVC protection is automatically enabled on Kubernetes starting from version 1.10.

Yes. You can expand a PVC that has been created by Trident. Note that volume autogrow is an ONTAP feature that is not applicable to Trident.

The volume import fails if the external volume is in DP mode or is offline. You receive the following error message:

Kubernetes Storage Resource Quota should work as long as NetApp storage has capacity. When the NetApp storage cannot honor the Kubernetes quota settings due to lack of capacity, Trident tries to provision but errors out.

Yes. Creating on-demand volume snapshots and Persistent Volumes from Snapshots are supported by Trident. To create PVs from snapshots, ensure that the VolumeSnapshotDataSource feature gate has been enabled.

As of today, on-demand snapshot support is available for our ontap-nas, ontap-nas-flexgroup, ontap-san, ontap-san-economy, solidfire-san, gcp-cvs, and azure-netapp-files backend drivers.

This is available on ontap-nas, ontap-san, and ontap-nas-flexgroup drivers. You can also specify a snapshotPolicy for the ontap-san-economy driver at the FlexVol level.

This is also available on the ontap-nas-economy drivers but on the FlexVol level granularity and not on the qtree level granularity. To enable the ability to snapshot volumes provisioned by Trident, set the backend parameter option snapshotPolicy to the desired snapshot policy as defined on the ONTAP backend. Any snapshots taken by the storage controller are not known by Trident.

Yes, you can reserve a specific percentage of disk space for storing the snapshot copies through Trident by setting the snapshotReserve attribute in the backend definition file. If you have configured snapshotPolicy and snapshotReserve in the backend definition file, snapshot reserve percentage is set according to the snapshotReserve percentage mentioned in the backend file. If the snapshotReserve percentage number is not mentioned, ONTAP by default takes the snapshot reserve percentage as 5. If the snapshotPolicy option is set to none, the snapshot reserve percentage is set to 0.

Yes, you can access the snapshot directory on the volume provisioned by Trident by setting the snapshotDir parameter in the backend definition file.

Currently, SnapMirror has to be set externally by using ONTAP CLI or OnCommand System Manager.

To restore a volume to an ONTAP snapshot, perform the following steps:

Load-sharing mirrors can be created for root volumes of SVMs that serve data over NFS. ONTAP automatically updates load-sharing mirrors for volumes that have been created by Trident. This may result in delays in mounting volumes. When multiple volumes are created using Trident, provisioning a volume is dependent on ONTAP updating the load-sharing mirror.

Kubernetes does not allow storage classes in namespaces. However, you can use Kubernetes to limit usage of a specific storage class per namespace by using Storage Resource Quotas, which are per namespace. To deny a specific namespace access to specific storage, set the resource quota to 0 for that storage class.