Se il pod Trident non si accende correttamente (ad esempio, quando il pod Trident è bloccato in ContainerCreating con meno di due container pronti), in esecuzione kubectl -n trident describe deployment trident e. kubectl -n trident describe pod trident--** può fornire ulteriori informazioni. Ottenere i log di kubelet (ad esempio, via journalctl -xeu kubelet) può anche essere utile.

Se i log di Trident non contengono informazioni sufficienti, provare ad attivare la modalità di debug per Trident passando il -d contrassegnare il parametro install in base all'opzione di installazione.

È inoltre possibile ottenere i log di debug per ciascun backend includendo debugTraceFlags nella definizione di back-end. Ad esempio, Includi debugTraceFlags: {“api”:true, “method”:true,} Per ottenere chiamate API e attraversamenti dei metodi nei log di Trident. I backend esistenti possono avere debugTraceFlags configurato con un tridentctl backend update.

Quando si utilizza RedHat CoreOS, assicurarsi che iscsid è attivato sui nodi di lavoro e avviato per impostazione predefinita. Questa operazione può essere eseguita utilizzando OpenShift MachineConfigs o modificando i modelli di accensione.

Si tratta di un problema comune che potrebbe verificarsi quando si utilizza Trident con "Azure NetApp Files" è quando i segreti del tenant e del client provengono da una registrazione dell'applicazione con autorizzazioni insufficienti. Per un elenco completo dei requisiti Trident, vedere "Azure NetApp Files" configurazione.

In caso di problemi con il montaggio di un PV su un container, assicurarsi che rpcbind è installato e in esecuzione. Utilizzare il gestore dei pacchetti richiesto per il sistema operativo host e verificare se rpcbind è in esecuzione. È possibile controllare lo stato di rpcbind eseguire un systemctl status rpcbind o equivalente.

Se un backend Trident segnala che si trova in failed stato nonostante abbia lavorato in precedenza, è probabile che sia causato dalla modifica delle credenziali SVM/admin associate al backend. Aggiornamento delle informazioni di back-end tramite tridentctl update backend O rimbalzare il pod Trident risolverà questo problema.

Se stai aggiornando il tuo cluster Kubernetes e/o Trident per utilizzare le snapshot dei volumi beta, assicurati che tutti i CRS di snapshot alfa esistenti siano completamente rimossi. È quindi possibile utilizzare tridentctl obliviate alpha-snapshot-crd Comando per eliminare i CRD snapshot alfa. Vedere "questo blog" comprendere i passaggi necessari per la migrazione delle snapshot alfa.

Se si riscontrano problemi di autorizzazione durante l'installazione di Trident con Docker come runtime del container, tentare l'installazione di Trident con --in cluster=false allarme. Questo non utilizzerà un pod di installazione ed eviterà i problemi di autorizzazione causati da trident-installer utente.

Utilizzare uninstall parameter <Uninstalling Trident> per la pulizia dopo un'esecuzione non riuscita. Per impostazione predefinita, lo script non rimuove i CRD creati da Trident, rendendo sicuro disinstallare e installare di nuovo anche in una distribuzione in esecuzione.

Se si desidera eseguire il downgrade a una versione precedente di Trident, eseguire prima il tridenctl uninstall Comando per rimuovere Trident. Scaricare il desiderato "Versione di Trident" e installare utilizzando tridentctl install comando. Considerare un downgrade solo se non sono stati creati nuovi PVS e se non sono state apportate modifiche alle classi di storage/backend/PVS già esistenti. Poiché Trident utilizza ora i CRD per mantenere lo stato, tutte le entità di storage create (backend, classi di storage, PVS e snapshot dei volumi) ne hanno associated CRD objects <Kubernetes CustomResourceDefinition Objects> Invece dei dati scritti nel PV utilizzati dalla versione precedente di Trident. Il PVS appena creato non sarà utilizzabile quando si torna a una versione precedente. le modifiche apportate agli oggetti, come backend, PVS, classi di storage e snapshot di volumi (creati/aggiornati/cancellati) non saranno visibili a Trident quando si esegue il downgrade. Il PV utilizzato dalla versione precedente di Trident installata sarà ancora visibile a Trident. Il ritorno a una versione precedente non interrompe l'accesso ai PVS già creati utilizzando la versione precedente, a meno che non siano stati aggiornati.

Per rimuovere completamente Trident, eseguire tridentctl obliviate crd comando. In questo modo verranno rimossi tutti gli oggetti CRD e i CRD non saranno definiti. Trident non gestirà più i PVS già forniti.

Trident dovrà essere riconfigurato da zero.

Una volta completata correttamente l'installazione, se un PVC è bloccato in Pending fase, esecuzione kubectl describe pvc Può fornire ulteriori informazioni sul motivo per cui Trident non ha eseguito il provisioning di un PV per questo PVC.