Trident: Das Trident CSI Node-Plug-in wird nach der Aktualisierung der Kubernetes-Version nicht mehr registriert

Erstellt am 25. Nov. 2020  ·  4Kommentare  ·  Quelle: NetApp/trident

Beschreiben Sie den Fehler

Das Trident-CSI-Knoten-Plugin ( csi.trident.netapp.io ) auf einem Knoten ist jetzt nicht mehr registriert, nachdem die Kubernetes-Version von v1.18.9 auf v1.19.4 aktualisiert wurde. Pods auf diesem Knoten können keine Trident-Volumes mehr mounten und unmounten.

Fehlermeldungen

Wir sehen die folgenden Nachrichten im Kubelet-Protokoll.

csi.trident.netapp.io wurde nicht registriert, da der Registrierungs-Socket ( /var/lib/kubelet/plugins_registry/csi.trident.netapp.io-reg.sock ) entfernt wurde.

I1119 05:47:54.246972 6550 plugin_watcher.go:212] Entfernen des Socket-Pfads /var/lib/kubelet/plugins_registry/csi.trident.netapp.io-reg.sock aus dem Cache für den gewünschten Zustand
I1119 05:47:53.162305 6550 reconciler.go:139] operationExecutor.UnregisterPlugin gestartet für Plug-in unter „/var/lib/kubelet/plugins_registry/csi.trident.netapp.io-reg.sock“ (Plug-in-Details: &{/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-Anfrage für Plugin csi.trident.netapp.io

Der Pod konnte das Volume nicht unmounten, da csi.trident.netapp.io nicht gefunden wurde.

E1119 09:02:52.819122 6550 nestedpendingoperations.go:301] Vorgang für „{v olumeName:kubernetes.io/csi/csi.trident.netapp.io ^pvc-75a6fd7f-7aee-45e8-a5fa-d4500272528e podName:ad18a7d1-4090 -4e0c-9e71-cba46dfc3657 Knotenname:}" fehlgeschlagen. Keine Wiederholungen zulässig bis 2020-11-19 09:04:54.819071328 +0000 UTC m=+1310234.159288938 (durationBeforeRetry 2m2s). Fehler: „UnmountVolume.TearDown für Volume „data“ (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 konnte CSI-Client nicht abrufen: Treibername csi.trident.netapp.io nicht in der Liste gefunden von registrierten CSI-Fahrern"

Zwei trident-csi liefen gleichzeitig

Wir haben festgestellt, dass zwei trident-csi -Pods (Knoten-Plug-in) auf diesem Knoten für eine sehr kurze Zeit gleichzeitig ausgeführt wurden und dass der alte driver-registrar gestoppt wurde, nachdem ein neuer gestartet wurde.

driver-registrar entfernt den Registrierungs-Socket ( /var/lib/kubelet/plugins_registry/csi.trident.netapp.io-reg.sock ), wenn es SIGTERM ( node_register.go#L113-L116 ) empfängt. Das Entfernen des Sockets führt dazu, dass das Kubelet das Trident-Plug-in deregistriert. Ich glaube, das ist die Ursache des Problems.

image

DaemonSet wurde nach der Aktualisierung neu erstellt

Trident-csi (Node Plugin)-Pods werden von DaemonSet verwaltet. Normalerweise läuft auf jedem Knoten nur ein Pod. Aber nachdem Kubernetes aktualisiert wurde, wurde trident-csi Daemonset von trident-operator neu erstellt. Durch das Löschen von DaemonSet können zwei Pods (alt und neu) gleichzeitig ausgeführt werden.

Wir haben dies im trident-operator -Protokoll bestätigt.

Hier wurde das trident-csi Daemonset gelöscht.

time="2020-11-19T05:47:45Z" level=debug msg="Deleted Kubernetes DaemonSet." DaemonSet=trident-csi namespace=trident

Das trident-csi Daemonset wurde dann kurz darauf erstellt.

time="2020-11-19T05:47:45Z" level=debug msg="Objekt erstellen." kind=DaemonSet name=trident-csi namespace=trident

Nach der Aktualisierung von Kubernetes wurde das Flag shouldUpdate auf true gesetzt ( controller.go#L1110 ). Es scheint, dass das Flag shouldUpdate bewirkt, dass das Daemonset trident-csi gelöscht wird ( installer.go#L1489-L1494 ).

Umfeld

  • Trident-Version: 20.10.0 mit Trident-Operator
  • Verwendete Trident-Installationsflags: silenceAutosupport: true (Trident Operator)
  • Containerlaufzeit: Docker 19.03.13
  • Kubernetes-Version: v1.19.4
  • Kubernetes-Orchestrierer: Kubernetes
  • Kubernetes-fähige Feature-Gates:
  • Betriebssystem: Ubuntu 18.04
  • NetApp-Backend-Typen: ONTAP AFF 9.1P14
  • Andere:

Reproduzieren

Das Aktualisieren der Kubernetes-Version kann dieses Problem reproduzieren. Da die Aktualisierung von Kubernetes lange dauert und nicht immer erfolgt, haben wir die folgenden Verhaltensweisen, die dieses Problem verursachen, durch verschiedene Demonstrationen bestätigt.

Zwei Trident-CSI veranlassen das Kubelet, die Registrierung des Trident-Plugins aufzuheben

  1. Bestätigen Sie, dass der Trident CSI-Treiber auf dem Knoten registriert ist.
$ 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. Kopieren Sie trident-csi DaemonSet, um zwei trident-csi-Pods auf jedem Knoten auszuführen.
$ kubectl get ds -n trident trident-csi -o json | jq '.metadata.name|="trident-csi-2"' | kubectl apply -f -
  1. Warten Sie, bis sie ausgeführt werden, und löschen Sie dann das kopierte trident-csi-2 DaemonSet.
$ kubectl delete ds -n trident trident-csi-2
  1. Bestätigen Sie, dass der Trident CSI-Treiber im Abschnitt Treiber auf dem Knoten verschwunden ist. (Dies wird einige Zeit dauern)
$ kubectl describe csinodes.storage.k8s.io <NODE_NAME>
Spec:

Durch die Neuerstellung von DaemonSet können zwei Pods (alt und neu) gleichzeitig ausgeführt werden

  1. Löschen Sie trident-csi DaemonSet. Das DaemonSet wird kurz darauf vom Trident-Operator neu erstellt.
$ kubectl delete ds -n trident trident-csi
  1. Auf jedem Knoten sehen Sie zwei trident-csi -Pods.
$ kubectl get pods -n trident -o wide

Erwartetes Verhalten
Pods können Trident-Volumes mounten und unmounten, nachdem die Kubernetes-Version aktualisiert wurde.

Zusätzlicher Kontext
Keiner

bug tracked

Hilfreichster Kommentar

Wir werden diesen Fix in die Version Trident v21.01 aufnehmen.

Alle 4 Kommentare

Hallo @tksm

Vielen Dank für die Bereitstellung von Details zu diesem Problem und die genaue Untersuchung der zugrunde liegenden Ursache. Ihre Analyse ist sehr hilfreich. Das Fenster zwischen der Beendigung des Daemonset-Pods und dem Abrufen der Wiederherstellung ist kritisch, und letzteres sollte nur auftreten, wenn ersteres abgeschlossen ist. Daher sollte der Betreiber sicherstellen, dass vor der Daemonset-Erstellung alle zum vorherigen Daemonset gehörenden Pods gelöscht werden und erst dann ein neues Daemonset erstellen.

Darf ich aus Neugier nach der Anzahl der Cluster fragen, bei denen dieses Problem während eines Upgrades aufgetreten ist?

Danke schön!

Hallo, @ntap-arorar

Vielen Dank für die Bestätigung. Ich denke, Ihre Idee wird dieses Problem beheben.

Wir sind bisher nur auf einem Cluster auf dieses Problem gestoßen, da wir nur wenige Cluster testweise aktualisiert hatten.

Wir werden diesen Fix in die Version Trident v21.01 aufnehmen.

Dieses Problem wurde mit Commit 820579d behoben .

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen