Trident: Échecs aléatoires du montage pvc dus à des délais d'attente blkid

Créé le 14 oct. 2020  ·  4Commentaires  ·  Source: NetApp/trident

Décrivez le bogue
Nous observons de nombreux pods bloqués au hasard à l'état ContainerCreating car ils ne peuvent pas monter les pvc netapp. La description des pods indique des délais d'attente lors de l'obtention d'informations sur le périphérique iSCSI et les journaux du démon de trident suggèrent que cela est dû à des délais d'attente lors de l'exécution de la commande blkid sur l'hôte.
Il s'agit d'un événement aléatoire et ne peut pas encore être corrélé avec certains pvc et hôtes.

Environnement

  • Version Trident : 20.07.1
  • Indicateurs d'installation de Trident utilisés : tridentctl install -n sys-trident --generate-custom-yaml (puis kubectl apply -f - pour les manifestes générés)
  • Exécution du conteneur : docker://19.3.12
  • Version de Kubernetes : v1.19.2
  • Orchestrateur Kubernetes : aucun
  • Portes de fonctionnalités activées par Kubernetes : valeurs par défaut de kubernetes uniquement
  • Système d'exploitation : Flatcar Container Linux par Kinvolk 2605.6.0 (Oklo) 5.4.67-flatcar
  • Types de backend NetApp : ontap-san, ONTAP 9.7.0

Reproduire
Nous pouvons l'observer au hasard sur nos nœuds de cluster (ne semble pas être lié à un groupe particulier d'hôtes)

Comportement attendu
Un comportement de montage cohérent dans une fenêtre de temps raisonnable.

Contexte supplémentaire
En décrivant un pod "bloqué", nous pouvons voir :

Events:
  Type     Reason       Age                  From     Message
  ----     ------       ----                 ----     -------
  Warning  FailedMount  51m (x5 over 72m)    kubelet  Unable to attach or mount volumes: unmounted volumes=[data], unattached volumes=[data thanos-storage vault-tls thanos-store-token-lj9j5]: timed out waiting for the condition
  Warning  FailedMount  42m (x3 over 56m)    kubelet  Unable to attach or mount volumes: unmounted volumes=[data], unattached volumes=[thanos-storage vault-tls thanos-store-token-lj9j5 data]: timed out waiting for the condition
  Warning  FailedMount  17m (x15 over 74m)   kubelet  Unable to attach or mount volumes: unmounted volumes=[data], unattached volumes=[vault-tls thanos-store-token-lj9j5 data thanos-storage]: timed out waiting for the condition
  Warning  FailedMount  14m (x22 over 74m)   kubelet  MountVolume.MountDevice failed for volume "pvc-e22cdf07-acfc-42af-a46a-bffd5ac32514" : rpc error: code = Internal desc = error getting iSCSI device information: process killed after timeout
  Warning  FailedMount  4m11s (x4 over 69m)  kubelet  Unable to attach or mount volumes: unmounted volumes=[data], unattached volumes=[thanos-store-token-lj9j5 data thanos-storage vault-tls]: timed out waiting for the condition

sur le même nœud à partir des journaux de pod respectifs du daemonset trident :

time="2020-10-14T14:32:41Z" level=debug msg=">>>> osutils.execCommandWithTimeout." args="[if=/dev/sdc bs=4096 count=1 status=none]" command=dd timeoutSeconds=5s
time="2020-10-14T14:32:41Z" level=debug msg="<<<< osutils.execCommandWithTimeout." command=dd error="<nil>"
time="2020-10-14T14:32:41Z" level=debug msg="<<<< osutils.ensureDeviceReadable"
time="2020-10-14T14:32:41Z" level=debug msg=">>>> osutils.getFSType" device=/dev/sdc
time="2020-10-14T14:32:41Z" level=debug msg=">>>> osutils.waitForDevice" device=/dev/sdc
time="2020-10-14T14:32:41Z" level=debug msg="Device found." device=/dev/sdc
time="2020-10-14T14:32:41Z" level=debug msg="<<<< osutils.waitForDevice" device=/dev/sdc
time="2020-10-14T14:32:41Z" level=debug msg=">>>> osutils.execCommandWithTimeout." args="[/dev/sdc]" command=blkid timeoutSeconds=5s
time="2020-10-14T14:32:46Z" level=error msg="process killed after timeout" process=blkid
time="2020-10-14T14:32:46Z" level=debug msg="<<<< osutils.execCommandWithTimeout." command=blkid error="process killed after timeout"
time="2020-10-14T14:32:46Z" level=debug msg="<<<< osutils.getFSType"
time="2020-10-14T14:32:46Z" level=debug msg="<<<< osutils.getDeviceInfoForLUN" iSCSINodeName="iqn.1992-08.com.netapp:sn.0205ffce026911ebb4d9d039ea1a7953:vs.9" lunID=1 needFSType=true
time="2020-10-14T14:32:46Z" level=debug msg="<<<< osutils.AttachISCSIVolume"
time="2020-10-14T14:32:46Z" level=debug msg="<<<< NodeStageVolume" Method=NodeStageVolume Type=CSI_Node
time="2020-10-14T14:32:46Z" level=debug msg="Released shared lock (NodeStageVolume-pvc-e22cdf07-acfc-42af-a46a-bffd5ac32514)." lock=csi_node_server
time="2020-10-14T14:32:46Z" level=error msg="GRPC error: rpc error: code = Internal desc = error getting iSCSI device information: process killed after timeout"

il semble que blkid ne puisse pas revenir dans la fenêtre de temps autorisée (?)
si nous nous connectons en ssh à l'hôte et essayons la même commande :

$ time sudo blkid /dev/sdc
/dev/sdc: UUID="f593b708-ed88-47b7-88ce-f9b8c85ab96b" TYPE="ext4"

real    0m36.393s
user    0m0.016s
sys     0m0.021s

notre configuration back-end json :
```
{
"version 1,
"storageDriverName": "ontap-san",
"managementLIF": "10.20.50.6",
"dataLIF": "10.20.50.4",
"svm": "dev_kube",
"igroupName": "dev_kube_trident",
"nom d'utilisateur": "xxxxxxxxx",
"mot de passe": "xxxxxxxxxxxx",
"par défaut": {
"cryptage": "vrai"
}
}
````

Nous sommes vraiment coincés ici, donc toute aide sur celui-ci sera très appréciée !

bug

Commentaire le plus utile

Fermeture de celui-ci car nous ne l'avons pas vu depuis que nous avons débogué la vitesse de nos liens réseau. Merci beaucoup pour l'aide! :))

Tous les 4 commentaires

Salut @ffilippopoulos ,

Comme vous l'avez souligné, blkid est une commande au niveau de l'hôte. La capacité de cette commande à revenir avant son expiration n'est pas quelque chose que Trident peut contrôler. Trident fait essentiellement la même chose que vous faites lorsque vous vous connectez en ssh à l'hôte et exécutez blkid à partir d'un shell. Avez-vous examiné la charge sur l'hôte ?

De même, si vous avez besoin d'une assistance immédiate pour résoudre ce problème, veuillez contacter le support NetApp.

Pour ouvrir un dossier auprès de NetApp, rendez-vous sur https://mysupport.netapp.com/site/.
En bas à gauche, cliquez sur "Contacter l'assistance"
Trouvez le numéro approprié de votre région pour appeler ou vous connecter.
Remarque : Trident n'est pas répertorié sur la page, mais est un produit pris en charge par NetApp basé sur un SN de stockage Netapp pris en charge.
Ouvrez le dossier sur le SN de stockage NetApp et fournissez la description du problème.
Assurez-vous de mentionner que le produit est Trident sur Kubernetes et fournissez les détails. Mentionnez ce GitHub.
Le cas sera dirigé vers les ingénieurs de support Trident pour réponse.

salut @gnarl merci pour la réponse rapide. Autant que je sache, il y a cependant un délai d'attente de 5 secondes sur cette commande, qui se trouve sur le champ tridents: https://github.com/NetApp/trident/blob/0a245d3895af31f910a58c2f26e5a0f8b25f34f8/utils/osutils.go#L2306

pour autant que je sache, nos nœuds ne sont pas du tout chargés (par exemple, sur le nœud, nous voyons maintenant le problème load average: 0.54, 0.62, 0.61 ) et je ne pense pas que cela expliquerait le comportement que nous observons.
Y a-t-il une raison pour le délai d'attente codé en dur ? empêche-t-il un cas dont nous ne sommes pas au courant ?

@ffilippopoulos , blkid ne devrait pas prendre près de 5 secondes pour s'exécuter. Si la charge sur votre hôte semble bonne, pouvez-vous examiner la latence du réseau entre l'hôte et la dataLIF NetApp ?

Nous avons un délai d'attente difficile sur blkid car si blkid ne fonctionne pas, Trident ne peut pas attacher le volume en toute sécurité.

Fermeture de celui-ci car nous ne l'avons pas vu depuis que nous avons débogué la vitesse de nos liens réseau. Merci beaucoup pour l'aide! :))

Cette page vous a été utile?
0 / 5 - 0 notes