Beschreiben Sie den Fehler
Wir beobachten, dass viele Pods zufällig im ContainerCreating
-Zustand hängen bleiben, weil sie NetApp-PVCs nicht mounten können. Das Beschreiben von Pods weist auf Zeitüberschreitungen beim Abrufen von iSCSI-Geräteinformationen hin, und Trident-Daemonset-Protokolle deuten darauf hin, dass dies auf Zeitüberschreitungen beim Ausführen des blkid
-Befehls auf dem Host zurückzuführen ist.
Dies ist ein Zufallsereignis und kann noch nicht mit bestimmten pvcs und Hosts korrelieren.
Umfeld
Reproduzieren
Wir können es zufällig auf unseren Cluster-Knoten beobachten (scheint nicht mit einer bestimmten Gruppe von Hosts zusammenzuhängen)
Erwartetes Verhalten
Ein konsistentes Mount-Verhalten innerhalb eines angemessenen Zeitfensters.
Zusätzlicher Kontext
Durch die Beschreibung eines "hängengebliebenen" Pods können wir sehen:
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
auf demselben Knoten aus dem Trident-Daemonset die entsprechenden Pod-Protokolle:
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"
Es sieht so aus, als ob blkid
nicht im zulässigen Zeitfenster zurückkehren kann (?)
wenn wir in den Host ssh und denselben Befehl versuchen:
$ time sudo blkid /dev/sdc
/dev/sdc: UUID="f593b708-ed88-47b7-88ce-f9b8c85ab96b" TYPE="ext4"
real 0m36.393s
user 0m0.016s
sys 0m0.021s
unsere Backend-json-Konfiguration:
```
{
"Version 1,
"storageDriverName": "ontap-san",
"managementLIF": "10.20.50.6",
"dataLIF": "10.20.50.4",
"svm": "dev_kube",
"igroupName": "dev_kube_trident",
"Benutzername": "xxxxxxxxx",
"Passwort": "xxxxxxxxxxx",
"Standardeinstellungen": {
"Verschlüsselung": "true"
}
}
````
Wir stecken hier wirklich fest, also wird jede Hilfe in diesem Fall sehr geschätzt!
Hallo @ffilippopoulos ,
Wie Sie darauf hingewiesen haben, ist blkid ein Befehl auf Hostebene. Die Fähigkeit dieses Befehls, vor Ablauf des Zeitlimits zurückzukehren, kann Trident nicht kontrollieren. Trident macht im Grunde dasselbe, was Sie tun, wenn Sie in den Host ssh und blkid von einer Shell aus ausführen. Haben Sie die Auslastung des Hosts untersucht?
Wenn Sie bei diesem Problem sofortige Hilfe benötigen, wenden Sie sich bitte an den NetApp Support.
Um einen Fall bei NetApp zu eröffnen, gehen Sie bitte zu https://mysupport.netapp.com/site/.
Klicken Sie unten links auf „Support kontaktieren“.
Finden Sie die entsprechende Nummer aus Ihrer Region, um sich anzurufen oder anzumelden.
Hinweis: Trident wird nicht auf der Seite aufgeführt, ist jedoch ein unterstütztes Produkt von NetApp, das auf einem unterstützten Netapp-Speicher-SN basiert.
Öffnen Sie den Fall auf dem NetApp Storage SN und geben Sie eine Beschreibung des Problems an.
Erwähnen Sie unbedingt, dass das Produkt Trident on Kubernetes ist, und geben Sie die Details an. Erwähnen Sie diesen GitHub.
Der Fall wird zur Beantwortung an Trident-Supporttechniker weitergeleitet.
Hey @gnarl danke für die schnelle Antwort. Soweit ich sehen kann, gibt es bei diesem Befehl jedoch eine harte Zeitüberschreitung von 5 Sekunden, die sich im Tridents-Feld befindet: https://github.com/NetApp/trident/blob/0a245d3895af31f910a58c2f26e5a0f8b25f34f8/utils/osutils.go#L2306
Soweit ich sehen kann, werden unsere Knoten überhaupt nicht geladen (zum Beispiel sehen wir auf dem Knoten jetzt das Problem load average: 0.54, 0.62, 0.61
) und glauben nicht, dass dies das von uns beobachtete Verhalten erklären würde.
Gibt es einen Grund für die fest codierte Zeitüberschreitung? Verhindert es einen Fall, von dem wir nichts wissen?
@ffilippopoulos , blkid sollte nicht annähernd 5 Sekunden dauern, um zu laufen. Wenn die Last auf Ihrem Host gut aussieht, können Sie die Netzwerklatenz zwischen dem Host und dem NetApp dataLIF untersuchen?
Wir haben eine harte Zeitüberschreitung bei blkid, da Trident das Volume nicht sicher anhängen kann, wenn blkid nicht funktioniert.
Schließen Sie dieses, da wir es nicht gesehen haben, seit wir unsere Netzwerkverbindungsgeschwindigkeit debuggt haben. Vielen Dank für die Hilfe! :))
Hilfreichster Kommentar
Schließen Sie dieses, da wir es nicht gesehen haben, seit wir unsere Netzwerkverbindungsgeschwindigkeit debuggt haben. Vielen Dank für die Hilfe! :))