La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Dépannage

10/29/2025 Contributeurs

Utilisez les indications fournies ici pour résoudre les problèmes que vous pourriez rencontrer lors de l'installation et de l'utilisation de Trident.

Pour obtenir de l'aide concernant Trident, créez un dossier de support en utilisant tridentctl logs -a -n trident et envoyez-le au support NetApp .

Dépannage général

Si la capsule Trident ne remonte pas correctement (par exemple, si la capsule Trident est bloquée dans le ContainerCreating phase avec moins de deux conteneurs prêts), en cours d'exécution kubectl -n trident describe deployment trident et kubectl -n trident describe pod trident--** peut fournir des informations complémentaires. Obtention des journaux kubelet (par exemple, via journalctl -xeu kubelet ) peut également être utile.
Si les journaux de Trident ne contiennent pas suffisamment d'informations, vous pouvez essayer d'activer le mode débogage pour Trident en passant le -d Attribut au paramètre d'installation en fonction de votre option d'installation.

Vérifiez ensuite que le mode débogage est activé. ./tridentctl logs -n trident et à la recherche de level=debug msg dans le journal.
Installé avec l'opérateur
kubectl patch torc trident -n <namespace> --type=merge -p '{"spec":{"debug":true}}'

Cela redémarrera tous les pods Trident , ce qui peut prendre plusieurs secondes. Vous pouvez le vérifier en observant la colonne « ÂGE » dans le résultat de kubectl get pod -n trident .

Pour Trident 20.07 et 20.10, utilisez tprov au lieu de torc .
Installé avec Helm
helm upgrade <name> trident-operator-21.07.1-custom.tgz --set tridentDebug=true`
Installé avec tridentctl
./tridentctl uninstall -n trident ./tridentctl install -d -n trident
Vous pouvez également obtenir des journaux de débogage pour chaque backend en incluant debugTraceFlags dans votre définition de backend. Par exemple, inclure debugTraceFlags: {"api":true, "method":true,} pour obtenir les appels d'API et les parcours de méthodes dans les journaux Trident . Les backends existants peuvent avoir debugTraceFlags configuré avec un tridentctl backend update .
Lors de l'utilisation de Red Hat Enterprise Linux CoreOS (RHCOS), assurez-vous que iscsid est activé sur les nœuds de travail et démarré par défaut. Cela peut se faire en utilisant les configurations de machines OpenShift ou en modifiant les modèles d'allumage.
Un problème courant que vous pourriez rencontrer lors de l'utilisation de Trident avec "Azure NetApp Files" Cela se produit lorsque les secrets du locataire et du client proviennent d'un enregistrement d'application avec des autorisations insuffisantes. Pour obtenir la liste complète des exigences du Trident , veuillez consulter le site web suivant :"Azure NetApp Files" configuration.
En cas de problème lors du montage d'un panneau photovoltaïque sur un conteneur, assurez-vous que rpcbind est installé et fonctionne. Utilisez le gestionnaire de paquets requis pour le système d'exploitation hôte et vérifiez si rpcbind est en cours d'exécution. Vous pouvez vérifier l'état du rpcbind service en exécutant un systemctl status rpcbind ou son équivalent.
Si un serveur Trident signale qu'il est dans le failed Bien que cet état ait fonctionné auparavant, il est probablement dû à la modification des identifiants SVM/administrateur associés au serveur. Mise à jour des informations du backend à l'aide de tridentctl update backend ou faire rebondir la capsule Trident résoudra ce problème.
Si vous rencontrez des problèmes d'autorisation lors de l'installation de Trident avec Docker comme environnement d'exécution de conteneurs, essayez d'installer Trident avec… --in cluster=false drapeau. Cela n'utilisera pas de pod d'installation et évitera les problèmes d'autorisation rencontrés en raison de trident-installer utilisateur.
Utilisez le uninstall parameter <Uninstalling Trident> pour le nettoyage après un échec. Par défaut, le script ne supprime pas les CRD créées par Trident, ce qui permet de désinstaller et de réinstaller en toute sécurité même dans un déploiement en cours d'exécution.
Si vous souhaitez revenir à une version antérieure de Trident, exécutez d'abord la commande suivante : tridentctl uninstall commande pour supprimer Trident. Téléchargez le fichier souhaité "Version Trident" et installez en utilisant le tridentctl install commande.
Après une installation réussie, si un tuyau en PVC est coincé dans le Pending phase, course kubectl describe pvc peut fournir des informations supplémentaires sur les raisons pour lesquelles Trident n'a pas pu provisionner un PV pour ce PVC.

Déploiement Trident infructueux avec l'opérateur

Si vous déployez Trident à l'aide de l'opérateur, l'état de TridentOrchestrator changements de Installing à Installed . Si vous observez le Failed Si l'état est incorrect et que l'opérateur ne parvient pas à se rétablir par lui-même, vous devez consulter les journaux de l'opérateur en exécutant la commande suivante :

tridentctl logs -l trident-operator

L'analyse des journaux du conteneur trident-operator peut permettre de localiser l'origine du problème. Par exemple, un tel problème pourrait être l'impossibilité de récupérer les images de conteneurs requises à partir des registres en amont dans un environnement isolé du réseau.

Pour comprendre pourquoi l'installation de Trident a échoué, il convient de consulter le TridentOrchestrator statut.

kubectl describe torc trident-2
Name:         trident-2
Namespace:
Labels:       <none>
Annotations:  <none>
API Version:  trident.netapp.io/v1
Kind:         TridentOrchestrator
...
Status:
  Current Installation Params:
    IPv6:
    Autosupport Hostname:
    Autosupport Image:
    Autosupport Proxy:
    Autosupport Serial Number:
    Debug:
    Image Pull Secrets:         <nil>
    Image Registry:
    k8sTimeout:
    Kubelet Dir:
    Log Format:
    Silence Autosupport:
    Trident Image:
  Message:                      Trident is bound to another CR 'trident'
  Namespace:                    trident-2
  Status:                       Error
  Version:
Events:
  Type     Reason  Age                From                        Message
  ----     ------  ----               ----                        -------
  Warning  Error   16s (x2 over 16s)  trident-operator.netapp.io  Trident is bound to another CR 'trident'

Cette erreur indique qu'il existe déjà un TridentOrchestrator qui a été utilisé pour installer Trident. Étant donné que chaque cluster Kubernetes ne peut avoir qu'une seule instance de Trident, l'opérateur garantit qu'à tout moment, il n'existe qu'une seule instance active. TridentOrchestrator qu'elle peut créer.

De plus, l'observation de l'état des capsules Trident peut souvent indiquer si quelque chose ne va pas.

kubectl get pods -n trident

NAME                                READY   STATUS             RESTARTS   AGE
trident-csi-4p5kq                   1/2     ImagePullBackOff   0          5m18s
trident-csi-6f45bfd8b6-vfrkw        4/5     ImagePullBackOff   0          5m19s
trident-csi-9q5xc                   1/2     ImagePullBackOff   0          5m18s
trident-csi-9v95z                   1/2     ImagePullBackOff   0          5m18s
trident-operator-766f7b8658-ldzsv   1/1     Running            0          8m17s

On constate clairement que les pods ne peuvent pas s'initialiser complètement car une ou plusieurs images de conteneur n'ont pas été récupérées.

Pour résoudre ce problème, vous devriez modifier le TridentOrchestrator CR. Vous pouvez également supprimer TridentOrchestrator et en créer une nouvelle avec la définition modifiée et précise.

Déploiement Trident infructueux utilisant `tridentctl`

Pour tenter de comprendre ce qui s'est mal passé, vous pouvez relancer le programme d'installation en utilisant-d argument, qui activera le mode débogage et vous aidera à comprendre quel est le problème :

./tridentctl install -n trident -d

Après avoir résolu le problème, vous pouvez nettoyer l'installation comme suit, puis exécuter le programme. tridentctl install commande à nouveau :

./tridentctl uninstall -n trident
INFO Deleted Trident deployment.
INFO Deleted cluster role binding.
INFO Deleted cluster role.
INFO Deleted service account.
INFO Removed Trident user from security context constraint.
INFO Trident uninstallation succeeded.

Supprimer complètement Trident et CRD

Vous pouvez supprimer complètement Trident ainsi que toutes les CRD créées et les ressources personnalisées associées.

Cela ne peut pas être annulé. Ne faites pas cela à moins de vouloir une installation entièrement neuve de Trident. Pour désinstaller Trident sans supprimer les CRD, reportez-vous à"Désinstaller Trident" .

Opérateur Trident

Pour désinstaller Trident et supprimer complètement les CRD à l'aide de l'opérateur Trident :

kubectl patch torc <trident-orchestrator-name> --type=merge -p '{"spec":{"wipeout":["crds"],"uninstall":true}}'

Barre

Pour désinstaller Trident et supprimer complètement les CRD à l'aide de Helm :

kubectl patch torc trident --type=merge -p '{"spec":{"wipeout":["crds"],"uninstall":true}}'

<code>tridentctl</code>

Pour supprimer complètement les CRD après la désinstallation de Trident, utilisez tridentctl

tridentctl obliviate crd

Échec du déstockage des nœuds NVMe avec les espaces de noms de blocs bruts RWX sous Kubernetes 1.26

Si vous utilisez Kubernetes 1.26, la suppression des nœuds peut échouer lors de l'utilisation de NVMe/TCP avec des espaces de noms de blocs bruts RWX. Les scénarios suivants proposent des solutions de contournement à cette défaillance. Vous pouvez également mettre à niveau Kubernetes vers la version 1.27.

Suppression de l'espace de noms et du pod

Prenons l’exemple d’un espace de noms géré par Trident (volume persistant NVMe) attaché à un pod. Si vous supprimez l'espace de noms directement depuis le backend ONTAP , le processus de désinstallation se bloque après votre tentative de suppression du pod. Ce scénario n'a aucun impact sur le cluster Kubernetes ni sur les autres fonctions.

Solution de contournement

Démontez le volume persistant (correspondant à cet espace de noms) du nœud respectif et supprimez-le.

LIF de données bloquées

 If you block (or bring down) all the dataLIFs of the NVMe Trident backend, the unstaging process gets stuck when you attempt to delete the pod. In this scenario, you cannot run any NVMe CLI commands on the Kubernetes node.
.Solution de contournement
Mettez en service le système de fichiers dataLIFS pour rétablir toutes les fonctionnalités.

Suppression du mappage d'espace de noms

 If you remove the `hostNQN` of the worker node from the corresponding subsystem, the unstaging process gets stuck when you attempt to delete the pod. In this scenario, you cannot run any NVMe CLI commands on the Kubernetes node.
.Solution de contournement
Ajoutez le `hostNQN` retour au sous-système.

Les clients NFSv4.2 signalent un « argument non valide » après la mise à niveau ONTAP alors qu'ils s'attendent à ce que « v4.2-xattrs » soit activé

Après la mise à niveau ONTAP, les clients NFSv4.2 peuvent signaler des erreurs « argument non valide » lors de la tentative de montage des exportations NFSv4.2. Ce problème se produit lorsque le v4.2-xattrs l'option n'est pas activée sur le SVM. .Solution de contournement Activer le v4.2-xattrs option sur le SVM ou mise à niveau vers ONTAP 9.12.1 ou version ultérieure, où cette option est activée par défaut.