- If there was a failure during install, run
tridentctl logs -l all -n tridentand look for problems in the logs for the
trident-mainand CSI containers (when using the CSI provisioner). Alternatively, you can use
kubectl logsto retrieve the logs for the
- If the Trident pod fails to come up properly (e.g., when Trident pod is stuck
ContainerCreatingphase with fewer than 2 ready containers), running
kubectl -n trident describe deployment tridentand
kubectl -n trident describe pod trident-********-****can provide additional insights. Obtaining kubelet logs (e.g., via
journalctl -xeu kubelet) can also be helpful.
- If there’s not enough information in the Trident logs, you can try enabling
the debug mode for Trident by passing the
-dflag to the install parameter:
./tridentctl install -d -n trident.
- If there are problems with mounting a PV to a container, ensure that
rpcbindis installed and running. Use the required package manager for the host OS and check if
rpcbindis running. You can check the status of the
rpcbindservice by running a
systemctl status rpcbindor its equivalent.
- If you encounter permission issues when installing Trident with Docker as the container
runtime, attempt the installation of Trident with the
--in-cluster=falseflag. This will not use an installer pod and avoid permission troubles seen due to the
- The uninstall parameter can help with cleaning up after a failed run. By default the script does not remove the CRDs that have been created by Trident, making it safe to uninstall and install again even in a running deployment.
- If you are looking to downgrade to an earlier version of Trident, first execute the
tridenctl uninstallcommand to remove Trident. Download the desired Trident version and install using the
tridentctl installcommand. Only consider a downgrade if there are no new PVs created and if no changes have been made to already existing PVs/backends/ storage classes. Since Trident now uses CRDs for maintaining state, all storage entities created (backends, storage classes, PVs) have associated CRD objects instead of data written into the PV that was used by the earlier installed version of Trident. Newly created PVs will not be usable when moving back to an earlier version. Changes made to objects such as backends, PVs and storage classes (created/updated/deleted) will not be visible to Trident when downgraded. The PV that was used by the earlier version of Trident installed will still be visible to Trident. Going back to an earlier version will not disrupt access for PVs that were already created using the older release, unless they have been upgraded.
- To completely remove Trident, execute the
tridentctl obliviate crdcommand. This will remove all CRD objects and undefine the CRDs. Trident will no longer manage any PVs it had already provisioned. Remember that Trident will need to be reconfigured from scratch after this.
- After a successful install, if a PVC is stuck in the
kubectl describe pvccan provide additional information on why Trident failed to provsion a PV for this PVC.
- If you require further assistance, please create a support bundle via
tridentctl logs -a -n tridentand send it to NetApp Support.