Trident: CSINode ne contient pas de pilote csi.trident.netapp.io
La description
En utilisant l'opérateur trident et kubernetes 1.17.6, je suis capable de créer des volumes persistants, mais pas de les monter dans les pods.
Lors de l'obtention de la description du pod, l'erreur suivante est renvoyée :
CSINode does not contain driver csi.trident.netapp.io
Environnement
- Version trident : [20.07.1]
- Indicateurs d'installation de Trident utilisés : [pas d'indicateurs personnalisés, puisque nous utilisons l'emplacement par défaut /var/lib/kubelet]
- Exécution du conteneur : [Docker 19.3.12]
- Version de Kubernetes : [ 1.17.6]
- Orchestrateur Kubernetes : [aucun]
- Portes de fonctionnalité activées par Kubernetes : [aucune nécessaire]
- Système d'exploitation : [Centos 7 - 3.10.0-1062.12.1.el7.x86_64]
- Types de backend NetApp : [ OnTap 9.7 ]
- Autre:
Reproduire
Installez l'opérateur comme indiqué ici : https://netapp-trident.readthedocs.io/en/stable-v20.07/kubernetes/deploying/operator-deploy.html
Après avoir créé la classe de stockage et le consommateur, le pv est lié, mais le pod ne peut pas attacher le volume localement au travailleur
Comportement attendu
Le pod devait monter le volume et fonctionner. à la place, il reste simplement dans "en attente"
Contexte supplémentaire
Description du module :
```kubectl -n test describe po web-0
Avertissement FailedScheduling 11s (x2 sur 12s) erreur de planificateur par défaut lors de l'exécution du plug-in de filtre "VolumeBinding" pour le pod "web-0": le pod a des PersistentVolumeClaims immédiats non liés
Planificateur par défaut 9s programmé normal Test/web-0 attribué avec succès à hh1kbw02x
Avertissement FailedAttachVolume
Avertissement FailedAttachVolume
Logs from trident on this worker:
kubectl -n trident logs trident-csi-9sgrt -c trident-main -f kubectl -n trident logs trident-csi-9sgrt -c driver-registrar kubectl obtenir csinode hh1kbw02x -n trident -o yaml Journaux Kubelet :
time="2020-10-21T17:15:31Z" level=debug msg="n>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> nPUT https://10.111.4.90 :34571/trident/v1/node/hh1kbw02xnHeaders : map[Content-Type :[application/json]]nBody : {n "name": "hh1kbw02x",n "ips": [n "10.49.12.102",n "172.17.0.1"n ]n}n----------------------------------------------- -----------------------------------------------"
time="2020-10-21T17:15:32Z" level=debug msg="n<<<<<<<<<<<<<<<<<<<<<<<<<<<< <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Logs from registrar sidecar on this worker:
I1021 17:14:18.636803 6672 main.go:110] Version : v1.3.0-0-g6e9fff3e
I1021 17:14:18.636888 6672 main.go:120] Tentative d'ouverture d'une connexion gRPC avec : "/plugin/csi.sock"
I1021 17:14:18.636908 6672 connection.go:151] Connexion à unix:///plugin/csi.sock
I1021 17:14:18.637420 6672 main.go:127] Appel du pilote CSI pour découvrir le nom du pilote
I1021 17:14:18.637435 6672 connection.go:180] Appel GRPC : /csi.v1.Identity/GetPluginInfo
I1021 17:14:18.637442 6672 connection.go:181] Requête GRPC : {}
I1021 17:14:18.639851 6672 connection.go:183] Réponse GRPC : {"name":"csi.trident.netapp.io","vendor_version":"20.07.1"}
I1021 17:14:18.640235 6672 connection.go:184] Erreur GRPC :
I1021 17:14:18.640242 6672 main.go:137] Nom du pilote CSI : "csi.trident.netapp.io"
I1021 17:14:18.648537 6672 node_register.go:51] Démarrage du serveur d'enregistrement à : /registration/csi.trident.netapp.io-reg.sock
I1021 17:14:18.648666 6672 node_register.go:60] Le serveur d'enregistrement a démarré à : /registration/csi.trident.netapp.io-reg.sock
Description of csi node
apiVersion : stockage.k8s.io/v1
genre : CSINode
métadonnées :
créationHorodatage : 2020-09-10T07:58:40Z
nom: hh1kbw02x
Références du propriétaire :
genre : nœud
nom: hh1kbw02x
uid : d3db28d6-e2be-4ad4-8534-c853b2e025b5
ressourceVersion : "30914526"
lien autonome : /apis/storage.k8s.io/v1/csinodes/hh1kbw02x
uid : a764977a-be67-4ee9-8b7e-9aac304e0890
spécification :
pilotes : nuls
6 novembre 10:14:18 hh1kbw01x kubelet : I1106 10:14:18.883059 2393 conciliar.go:209] operationExecutor.VerifyControllerAttachedVolume démarré pour le volume "pvc-3bcc4e38-2e69-4541-9910-711d2c086671" (UniqueName : "kubernetes.io/" csi/csi.trident.netapp.io^pvc-3bcc4e38-2e69-4541-9910-711d2c086671") module "web-0" (UID : "a235d5f9-05bf-4c77-8a84-e48f2f657d98")
6 novembre 10:14:18 hh1kbw01x kubelet : E1106 10:14:18.883223 2393 nestedpendingoperations.go:301] Opération pour "{v olumeName:kubernetes.io/csi/csi.trident.netapp.io ^pvc-3bcc4e38-2e69- 4541-9910-711d2c086671 podName : nodeName :}" a échoué. Aucune nouvelle tentative n'est autorisée jusqu'au 2020-11-06 10:14:19.383183856 +0100 CET m=+1353591.737508759 (durationBeforeRetry 500ms). Erreur : "Le volume n'a pas été ajouté à la liste des VolumesInUse dans l'état du volume du nœud pour le volume "pvc-3bcc4e38-2e69-4541-9910-711d2c086671" (UniqueName : "kubernetes.io/csi/csi.trident.netapp.io ^pvc-3bcc4e38-2e69-4541-9910-711d2c086671") module "web-0" (UID : "a235d5f9-05bf-4c77-8a84-e48f2f657d98") "
6 novembre 10:14:18 hh1kbw01x kubelet : I1106 10:14:18.983580 2393 conciliar.go:209] operationExecutor.VerifyControllerAttachedVolume démarré pour le volume "pvc-f138b6cc-988b-455c-bb2e-fce022755634" (UniqueName : "kubernetes.io/ csi/csi.trident.netapp.io^pvc-f138b6cc-988b-455c-bb2e-fce022755634") module "web-0" (UID : "a235d5f9-05bf-4c77-8a84-e48f2f657d98")
6 novembre 10:14:18 hh1kbw01x kubelet : E1106 10:14:18.983662 2393 nestedpendingoperations.go:301] Opération pour "{v olumeName:kubernetes.io/csi/csi.trident.netapp.io ^pvc-f138b6cc-988b- 455c-bb2e-fce022755634 podName : nodeName :}" a échoué. Aucune nouvelle tentative autorisée jusqu'au 2020-11-06 10:14:19.483629729 +0100 CET m=+1353591.837954619 (durationBeforeRetry 500ms). Erreur : "Le volume n'a pas été ajouté à la liste des VolumesInUse dans l'état du volume du nœud pour le volume "pvc-f138b6cc-988b-455c-bb2e-fce022755634" (UniqueName : "kubernetes.io/csi/csi.trident.netapp.io ^pvc-f138b6cc-988b-455c-bb2e-fce022755634") module "web-0" (UID : "a235d5f9-05bf-4c77-8a84-e48f2f657d98") "
6 novembre 10:14:19 hh1kbw01x kubelet : I1106 10:14:19.385072 2393 conciliar.go:209] operationExecutor.VerifyControllerAttachedVolume démarré pour le volume "pvc-3bcc4e38-2e69-4541-9910-711d2c086671" (UniqueName : "kubernetes.io/" csi/csi.trident.netapp.io^pvc-3bcc4e38-2e69-4541-9910-711d2c086671") module "web-0" (UID : "a235d5f9-05bf-4c77-8a84-e48f2f657d98")
```
alexandru-ersenie
Tous les 6 commentaires
Problème identique ici avec Rancher RKE et K8S (v1.18.10) et les nœuds exécutant Ubuntu 18.04.4 LTS avec Docker 19.3.13 reste correspond à l'environnement indiqué ci-dessus...
smangelkramer
le 30 oct. 2020
pareil ici avec k8s en amont sur ubuntu 18.04
AndreasDeCrinis
le 13 nov. 2020
J'ai pu le "résoudre" en redéployant à la fois le daemonset trident-csi et le déploiement et en redémarrant kubelet par la suite
AndreasDeCrinis
le 13 nov. 2020
Ouais. j'ai utilisé tridentctl au lieu de l'opérateur.
smangelkramer
le 13 nov. 2020
Donc j'ai corrigé, si je puis dire. Après avoir lu le fonctionnement du fournisseur de stockage externe et compris le concept d'enregistrement du conducteur à l'aide du conteneur side-car, j'ai passé en revue notre configuration.
C'était très trompeur, puisque nous configurons nos kubelets pour commencer avec les fichiers de configuration résidant sous /var/lib/kubelet, qui est le répertoire racine par défaut.
Il y a quelques mois, nous avons décidé de diviser le cerveau et de déplacer les dosettes et les conteneurs dans un lieu de stockage séparé. Nous avons donc séparé la gestion de l'exploitation.
Par conséquent, nous avons changé le répertoire racine dans le fichier de configuration pour qu'il pointe vers /containers au lieu de /var/lib/kubelet
Le fournisseur de trident par défaut cherchera dans l'emplacement par défaut et "intégrera" les plugins, pour ainsi dire.
Il faut donc vérifier deux choses :
ps aux | grep kubelet | grep -e 'root-dir-> prendre le dossier configuré (dans mon cas c'était /container)- changez le trident_provisioner_cr.yaml, et personnalisez-le en ajoutant le paramètre " kubeletDir "
apiVersion: trident.netapp.io/v1 kind: TridentProvisioner metadata: name: trident namespace: trident spec: debug: true kubeletDir: /container
Bonne chance. Je ferme ça.
alexandru-ersenie
le 19 nov. 2020
Observé quelque chose de similaire lorsque les pods daemonset trident-csi sont incapables de communiquer avec le trident-controller . Dans ce cas, cela était dû à une politique de réseau qui l'en empêchait.
balaramesh
le 7 déc. 2021
Questions connexes
acsulli
·
4Commentaires
gnarl
·
5Commentaires
takuhiro
·
5Commentaires
tksm
·
4Commentaires
timvandevoort
·
5Commentaires
Commentaire le plus utile
Donc j'ai corrigé, si je puis dire. Après avoir lu le fonctionnement du fournisseur de stockage externe et compris le concept d'enregistrement du conducteur à l'aide du conteneur side-car, j'ai passé en revue notre configuration.
C'était très trompeur, puisque nous configurons nos kubelets pour commencer avec les fichiers de configuration résidant sous /var/lib/kubelet, qui est le répertoire racine par défaut.
Il y a quelques mois, nous avons décidé de diviser le cerveau et de déplacer les dosettes et les conteneurs dans un lieu de stockage séparé. Nous avons donc séparé la gestion de l'exploitation.
Par conséquent, nous avons changé le répertoire racine dans le fichier de configuration pour qu'il pointe vers /containers au lieu de /var/lib/kubelet
Le fournisseur de trident par défaut cherchera dans l'emplacement par défaut et "intégrera" les plugins, pour ainsi dire.
Il faut donc vérifier deux choses :
ps aux | grep kubelet | grep -e 'root-dir-> prendre le dossier configuré (dans mon cas c'était /container)apiVersion: trident.netapp.io/v1 kind: TridentProvisioner metadata: name: trident namespace: trident spec: debug: true kubeletDir: /containerBonne chance. Je ferme ça.