Trident: Le plug-in Trident CSI Node n'est pas enregistré après la mise à jour de la version de Kubernetes

Décrivez le bogue

Le plug-in Trident CSI Node ( csi.trident.netapp.io ) sur un nœud est désormais désenregistré après la mise à jour de la version Kubernetes de la v1.18.9 à la v1.19.4. Les pods sur ce nœud ne peuvent plus monter et démonter des volumes Trident.

Messages d'erreur

Nous voyons les messages suivants dans le journal kubelet.

csi.trident.netapp.io n'a pas été enregistré car le socket d'enregistrement ( /var/lib/kubelet/plugins_registry/csi.trident.netapp.io-reg.sock ) a été supprimé.

I1119 05:47:54.246972 6550 plugin_watcher.go:212] Suppression du chemin de socket /var/lib/kubelet/plugins_registry/csi.trident.netapp.io-reg.sock du cache d'état souhaité
I1119 05:47:53.162305 6550 réconciliationr.go:139] operationExecutor.UnregisterPlugin a démarré pour le plugin à "/var/lib/kubelet/plugins_registry/csi.trident.netapp.io-reg.sock" (détails du plugin : &{/var /lib/kubelet/plugins_registry/csi.trident.netapp.io-reg.sock 2020-11-04 05:08:19.553684094 +0000 UTC m=+38.893901704 0x704c200 csi.trident.netapp.io})
I1119 05:47:53.163390 6550 csi_plugin.go:177] kubernetes.io/csi : registrationHandler.DeRegisterPlugin demande pour le plug-in csi.trident.netapp.io

Le pod n'a pas pu démonter le volume car csi.trident.netapp.io n'a pas été trouvé.

E1119 09:02:52.819122 6550 nestedpendingoperations.go:301] Opération pour "{v olumeName:kubernetes.io/csi/csi.trident.netapp.io ^pvc-75a6fd7f-7aee-45e8-a5fa-d4500272528e podName:ad18a7d1-4090 -4e0c-9e71-cba46dfc3657 nodeName :}" a échoué. Aucune nouvelle tentative n'est autorisée jusqu'au 2020-11-19 09:04:54.819071328 +0000 UTC m=+1310234.159288938 (durationBeforeRetry 2m2s). Erreur : "UnmountVolume.TearDown a échoué pour le volume "données" (UniqueName : "kubernetes.io/csi/csi.trident.netapp.io^pvc-75a6fd7f-7aee-45e8-a5fa-d4500272528e") pod "ad18a7d1-4090-4e0c -9e71-cba46dfc3657" (UID : "ad18a7d1-4090-4e0c-9e71-cba46dfc3657") : kubernetes.io/csi : mounter.SetUpAt n'a pas réussi à obtenir le client CSI : le nom du pilote csi.trident.netapp.io est introuvable dans la liste de pilotes inscrits au CSI"

Deux trident-csi fonctionnaient simultanément

Nous avons constaté que deux pods trident-csi (Node Plugin) sur ce nœud fonctionnaient simultanément pendant une très courte période et que l'ancien driver-registrar s'était arrêté après le démarrage d'un nouveau.

driver-registrar supprime le socket d'enregistrement ( /var/lib/kubelet/plugins_registry/csi.trident.netapp.io-reg.sock ) lorsqu'il reçoit SIGTERM ( node_register.go#L113-L116 ). La suppression du socket entraîne la désinscription du plug-in Trident par le kubelet. Je crois que c'est la cause du problème.

DaemonSet a été recréé après la mise à jour

Les pods Trident-csi (Node Plugin) sont gérés par DaemonSet. Normalement, un seul pod s'exécute sur chaque nœud. Mais après la mise à jour de Kubernetes, trident-csi Daemonset a été recréé par trident-operator . La suppression de DaemonSet permet à deux pods (ancien et nouveau) de s'exécuter simultanément.

Nous l'avons confirmé sur le journal trident-operator .

Ici, le trident-csi Daemonset a été supprimé.

time="2020-11-19T05:47:45Z" level=debug msg="Ensemble de démons Kubernetes supprimé." DaemonSet=espace de noms trident-csi=trident

Le trident-csi Daemonset a ensuite été créé peu de temps après.

time="2020-11-19T05:47:45Z" level=debug msg="Création d'un objet." kind=DaemonSet name=trident-csi namespace=trident

Après la mise à jour de Kubernetes, l'indicateur shouldUpdate a été défini sur true ( controller.go#L1110 ). Il semble que le drapeau shouldUpdate provoque la suppression du Daemonset trident-csi ( installer.go#L1489-L1494 ).

Environnement

• Version Trident : 20.10.0 avec opérateur trident
• Indicateurs d'installation Trident utilisés : silenceAutosupport: true (Opérateur Trident)
• Exécution du conteneur : Docker 19.03.13
• Version de Kubernetes : v1.19.4
• Orchestrateur Kubernetes : Kubernetes
• Portails de fonctionnalités activés par Kubernetes :
• Système d'exploitation : Ubuntu 18.04
• Types de backend NetApp : ONTAP AFF 9.1P14
• Autre:

Reproduire

La mise à jour de la version de Kubernetes peut reproduire ce problème. Étant donné que la mise à jour de Kubernetes prend beaucoup de temps et ne se produit pas toujours, nous avons confirmé les comportements suivants qui causent ce problème à travers différentes démonstrations.

Deux trident-csi entraînent la désinscription du plugin Trident par le kubelet

1. Vérifiez que le pilote Trident CSI est enregistré sur le nœud.

$ kubectl describe csinodes.storage.k8s.io <NODE_NAME>
...
Spec:
  Drivers:
    csi.trident.netapp.io:
      Node ID:        <NODE_NAME>
      Topology Keys:  [topology.kubernetes.io/zone]

1. Copiez trident-csi DaemonSet pour exécuter deux pods trident-csi sur chaque nœud.

$ kubectl get ds -n trident trident-csi -o json | jq '.metadata.name|="trident-csi-2"' | kubectl apply -f -

1. Attendez qu'ils s'exécutent, puis supprimez le DaemonSet trident-csi-2 copié.

$ kubectl delete ds -n trident trident-csi-2

1. Vérifiez que le pilote Trident CSI a disparu dans la section Pilotes du nœud. (Cela prendra un certain temps)

$ kubectl describe csinodes.storage.k8s.io <NODE_NAME>
Spec:

La recréation de DaemonSet permet à deux pods (ancien et nouveau) de s'exécuter simultanément

1. Supprimez trident-csi DaemonSet. Le DaemonSet sera recréé peu de temps après par l'opérateur trident.

$ kubectl delete ds -n trident trident-csi

1. Vous verrez deux pods trident-csi sur chaque nœud.

$ kubectl get pods -n trident -o wide

Comportement attendu
Les pods peuvent monter et démonter des volumes Trident après la mise à jour de la version de Kubernetes.

Contexte supplémentaire
Rien