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.
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"
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.
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
silenceAutosupport: true
(Trident Operator)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.
$ kubectl describe csinodes.storage.k8s.io <NODE_NAME>
...
Spec:
Drivers:
csi.trident.netapp.io:
Node ID: <NODE_NAME>
Topology Keys: [topology.kubernetes.io/zone]
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 -
trident-csi-2
DaemonSet.$ kubectl delete ds -n trident trident-csi-2
$ kubectl describe csinodes.storage.k8s.io <NODE_NAME>
Spec:
trident-csi
DaemonSet. Das DaemonSet wird kurz darauf vom Trident-Operator neu erstellt.$ kubectl delete ds -n trident trident-csi
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
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 .
Hilfreichster Kommentar
Wir werden diesen Fix in die Version Trident v21.01 aufnehmen.