Skip to main content
Astra Trident
21.07
La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Dépannage

Contributeurs

Utilisez les pointeurs indiqués ici pour résoudre les problèmes que vous pourriez rencontrer lors de l’installation et de l’utilisation d’Astra Trident.

Remarque Pour obtenir de l’aide avec Astra Trident, créez un bundle de support à l’aide de tridentctl logs -a -n trident et envoyez-le à NetApp Support <Getting Help>.
Astuce Pour obtenir une liste complète des articles de dépannage, reportez-vous au "Base de connaissances NetApp (identifiant requis)". Vous trouverez également des informations sur le dépannage des problèmes liés à Astra "ici".

Dépannage général

  • 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 indicateur du paramètre d’installation : ./tridentctl install -d -n trident.

  • 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.

    Remarque 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.

Dépannage d’un échec de déploiement Trident à l’aide de l’opérateur

Si vous déployez Trident à l’aide de l’opérateur, le statut de TridentOrchestrator modifications de Installing à Installed. Si vous observez l' Failed status, et l’opérateur ne peut pas récupérer en lui-même, il est recommandé de vérifier les journaux de l’opérateur en exécutant la commande suivante :

tridentctl logs -l trident-operator

Traînant les journaux du conteneur de l’opérateur trident peut pointer vers l’emplacement où se trouve le problème. Par exemple, un tel problème pourrait être l’impossibilité d’extraire les images de conteneur requises des registres en amont dans un environnement mis à l’air.

Pour comprendre pourquoi l’installation de Trident n’a pas été effectuée, consultez le TridentOrchestrator état.

$ 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:
    Enable Node Prep:
    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`Utilisé pour installer Trident. Étant donné que chaque cluster Kubernetes ne peut avoir qu’une seule instance de Trident, l’opérateur s’assure qu’une seule instance active existe à un instant donné `TridentOrchestrator qu’il peut créer.

De plus, l’observation de l’état des pods Trident peut souvent indiquer si quelque chose n’est pas approprié.

$ 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

Vous pouvez clairement voir que les modules ne peuvent pas être initialisés complètement parce qu’une ou plusieurs images de conteneur n’ont pas été extraites.

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

Dépannage d’un déploiement Trident non réussi à l’aide de tridentctl

Pour vous aider à déterminer ce qui s’est mal passé, vous pouvez exécuter à nouveau le programme d’installation à l’aide du -d argument, qui active le mode débogage et vous aide à comprendre 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 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.