For all ONTAP backends, Trident requires at least one aggregate assigned to the SVM.
Remember that you can also run more than one driver, and create storage
classes that point to one or the other. For example, you could configure a
san-dev class that uses the
ontap-san driver and a
san-default class that
All of your Kubernetes worker nodes must have the appropriate iSCSI tools installed. See the worker configuration guide for more details.
Trident uses igroups to control access to the volumes (LUNs) that it
provisions. It expects to find an igroup called
trident unless a different
igroup name is specified in the configuration.
While Trident associates new LUNs with the configured igroup, it does not create or otherwise manage igroups themselves. The igroup must exist before the storage backend is added to Trident.
If Trident is configured to function as a CSI Provisioner, Trident manages the addition of IQNs from worker nodes when mounting PVCs. As and when PVCs are attached to pods running on a given node, Trident adds the node’s IQN to the igroup configured in your backend definition.
If Trident does not run as a CSI Provisioner, the igroup must be manually updated to contain the iSCSI IQNs from every worker node in the Kubernetes cluster. The igroup needs to be updated when new nodes are added to the cluster, and they should be removed when nodes are removed as well.
Trident can authenticate iSCSI sessions with bidirectional CHAP beginning with 20.04
ontap-san-economy drivers. This requires enabling the
useCHAP option in your backend definition. When set to
configures the SVM’s default initiator security to bidirectional CHAP and set
the username and secrets from the backend file. The section below explains this