Si le pod Trident ne fonctionne pas correctement (par exemple, lorsque le pod Trident est coincé dans le ContainerCreating phase avec moins de deux conteneurs prêts à l'emploi), en cours d'exécution kubectl -n trident describe deployment trident et kubectl -n trident describe pod trident--** peut fournir des informations exploitables supplémentaires. Obtenir des journaux kubelet (par exemple, via journalctl -xeu kubelet) peut également être utile.

Si les journaux Trident ne contient pas suffisamment d'informations, vous pouvez essayer d'activer le mode de débogage pour Trident en passant le -d permet d'indiquer le paramètre d'installation en fonction de votre option d'installation.

Vous pouvez également obtenir des journaux de débogage pour chaque back-end en incluant debugTraceFlags dans votre définition de back-end. Par exemple, incluez debugTraceFlags: {“api”:true, “method”:true,} Pour obtenir des appels d'API et des transits de méthode dans les journaux Trident. Systèmes back-end existants peuvent avoir lieu debugTraceFlags configuré avec un tridentctl backend update.

Lorsque vous utilisez RedHat CoreOS, assurez-vous que cela iscsid est activé sur les nœuds workers et démarré par défaut. Pour ce faire, utilisez OpenShift MachineConfiguration ou modifiez les modèles d'allumage.

Un problème courant que vous pouvez rencontrer avec Trident "Azure NetApp Files" lorsque les secrets de locataire et de client proviennent d'un enregistrement d'application avec des autorisations insuffisantes. Pour obtenir la liste complète des exigences Trident, reportez-vous à la section "Azure NetApp Files" configuration.

En cas de problème de montage d'un PV sur un conteneur, vérifiez que rpcbind est installé et en cours d'exécution. Utilisez le gestionnaire de packages requis pour le système d'exploitation hôte et vérifiez si rpcbind est en cours d'exécution. Vous pouvez vérifier le statut de l' rpcbind service en exécutant un systemctl status rpcbind ou son équivalent.

Si un système Trident indique qu'il se trouve dans le failed État bien qu'il ait auparavant travaillé, il est probable que cela soit causé par la modification des identifiants SVM/admin associés au back-end. Mise à jour des informations du back-end à l'aide de tridentctl update backend Vous pouvez également rebondir sur le pod Trident pour résoudre ce problème.

Si vous mettez à niveau votre cluster Kubernetes et/ou Trident pour utiliser des snapshots de volume bêta, assurez-vous que tous les clichés alpha CRS existants sont entièrement supprimés. Vous pouvez ensuite utiliser le tridentctl obliviate alpha-snapshot-crd Commande permettant de supprimer des CRD alpha snapshot. Voir "de ce blog" pour comprendre les étapes de la migration des instantanés alpha.

Si vous rencontrez des problèmes d'autorisation lors de l'installation de Trident avec Docker comme conteneur d'exécution, essayez d'installer Trident avec le --in cluster=false drapeau. Ceci n'utilise pas de module d'installation et évite les problèmes de permission observés en raison de l' trident-installer utilisateur.

Utilisez le uninstall parameter <Uninstalling Trident> pour le nettoyage après un échec d'exécution. Par défaut, le script ne supprime pas les CRD créés par Trident, ce qui rend possible leur désinstallation et leur installation en toute sécurité, même dans le cadre d'un déploiement en cours d'exécution.

Si vous souhaitez revenir à une version antérieure de Trident, exécutez d'abord le tridenctl uninstall Commande de suppression de Trident. Télécharger le fichier désiré "Version Trident" et installer à l'aide de tridentctl install commande. N'envisagez une mise à niveau vers une version antérieure qu'en l'absence de nouveaux volumes persistants créés et si aucune modification n'a été apportée aux classes de stockage PVS/back-end existantes. Trident utilise désormais des CRD pour la maintenance de l'état, toutes les entités de stockage créées (back-end, classes de stockage, volumes persistants et copies Snapshot de volumes) associated CRD objects <Kubernetes CustomResourceDefinition Objects> Au lieu d'écrire les données dans le volume persistant, qui a été utilisé par la version précédente de Trident installée. Les nouveaux volumes persistants ne seront pas utilisables lors du déplacement vers une version antérieure. les modifications apportées aux objets, tels que les systèmes back-end, les volumes persistants, les classes de stockage et les instantanés de volumes (créés/mis à jour/supprimés) ne seront pas visibles dans Trident lors de la rétrogradation. Le volume persistant utilisé par la version précédente de Trident installé reste visible par Trident. Si vous revenez à une version antérieure, l'accès aux volumes persistants n'est pas perturbé et ceux qui ont déjà été créés à l'aide de cette version antérieure, sauf s'ils ont été mis à niveau.

Pour supprimer complètement Trident, exécutez le tridentctl obliviate crd commande. Ceci supprimera tous les objets CRD et dédéfinisse les CRD. Trident ne gérera plus les volumes persistants déjà provisionnés.

Trident devra être reconfiguré après coup.

Après une installation réussie, si un PVC est bloqué dans le Pending phase, exécution kubectl describe pvc Peut fournir des informations supplémentaires sur les raisons pour lesquelles Trident n'a pas pu provisionner un volume persistant pour cette demande de volume persistant.