Trident: Impossible de détacher les volumes attachés aux nœuds supprimés

Créé le 14 janv. 2022  ·  4Commentaires  ·  Source: NetApp/trident

Décrivez le bogue

Nous ne pouvons pas détacher les volumes attachés aux nœuds supprimés dans Trident 21.10.1. Dans Trident v21.07.2, ces volumes seraient automatiquement détachés après une certaine période. Si je comprends bien, ce détachement de force est effectué par AttachDetachController après ReconcilerMaxWaitForUnmountDuration .

Il semble que ce changement soit introduit dans ce commit . Ce commit oblige le ControllerUnpublishVolume de Trident à vérifier l'existence du nœud. Si le nœud n'existe pas, ControllerUnpublishVolume renvoie désormais une erreur NotFound , de sorte que le détachement du volume échoue toujours lorsque le nœud est déjà supprimé.

En cas de défaillance du serveur, le détachement de volume peut échouer et nous n'avons d'autre choix que de supprimer le nœud. Il est donc souhaitable de détacher automatiquement les volumes attachés aux nœuds supprimés.

Environnement

  • Version Trident : 21.10.1
  • Indicateurs d'installation Trident utilisés : silenceAutosupport: true (Opérateur Trident)
  • Exécution du conteneur : Docker 20.10.11
  • Version de Kubernetes : 1.22.5
  • Orchestrateur Kubernetes : Kubernetes
  • Portails de fonctionnalités activés par Kubernetes :
  • Système d'exploitation : Ubuntu 20.04.3 LTS
  • Types de backend NetApp : ONTAP AFF 9.7P13
  • Autre:

Reproduire

  • Créer un StatefulSet qui a un volume ontap-san
  • Supprimez l'objet nœud sur lequel le pod est planifié d'ici kubectl delete node
  • Le contrôleur StatefulSet recrée un nouveau pod sur un autre nœud après un court laps de temps
  • Le pod recréé ne peut pas être attaché au volume même après 1 heure

    • Avec Trident v21.07.2, le Pod deviendra Running après 6 à 8 minutes

Dans VolumeAttachment, l'erreur suivante peut être trouvée.

rpc error: code = NotFound desc = node <NODE_NAME> was not found'

Comportement attendu

Trident détache automatiquement les volumes attachés aux nœuds supprimés.

bug tracked
Source
picture tksm
👍3

Commentaire le plus utile

@paalkr , l'équipe travaille actuellement sur un correctif. Nous mettrons à jour ce problème avec un lien vers le commit une fois qu'il sera fusionné.

picture gnarl le 28 janv. 2022
👍2

Tous les 4 commentaires

Nous gérons un cluster Kubernetes de plus de 100 nœuds sur AWS qui s'appuie fortement sur des nœuds ponctuels. Les nœuds ponctuels seront résiliés avec seulement quelques minutes d'avertissement sur AWS, ce qui devrait se produire assez souvent. Même si nous exécutons le gestionnaire de terminaison de nœud en mode SQS et réagissons aux notifications de terminaison ponctuelles avec un drainage automatique des nœuds, nous nous retrouvons généralement dans une situation où le processus de détachement ne se termine pas avant la suppression d'un nœud.

Dans ce scénario, nous rencontrons souvent exactement le même problème que celui décrit par @tksm. Il s'agit d'un problème grave car les charges de travail seront bloquées dans un état de crash en boucle car le PVC ne parvient pas à se connecter après le déplacement du pod vers un nouveau nœud. J'espère que le problème pourra être corrigé.

paalkr picture paalkr le 14 janv. 2022
👍2

Une ETA sur un correctif ?

paalkr picture paalkr le 28 janv. 2022

@paalkr , l'équipe travaille actuellement sur un correctif. Nous mettrons à jour ce problème avec un lien vers le commit une fois qu'il sera fusionné.

gnarl picture gnarl le 28 janv. 2022
👍2

Excellent! Merci beaucoup.

paalkr picture paalkr le 28 janv. 2022
Cette page vous a été utile?
0 / 5 - 0 notes

Questions connexes

gnarl picture gnarl  ·  5Commentaires
mircster picture mircster  ·  6Commentaires
tksm picture tksm  ·  4Commentaires
takuhiro picture takuhiro  ·  5Commentaires
acsulli picture acsulli  ·  4Commentaires