Trident: Zufällige PVC-Mount-Fehler aufgrund von blkid-Zeitüberschreitungen

Erstellt am 14. Okt. 2020  ·  4Kommentare  ·  Quelle: NetApp/trident

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

  • Trident-Version: 20.07.1
  • Verwendete Trident-Installationsflags: tridentctl install -n sys-trident --generate-custom-yaml (dann kubectl apply -f - für die generierten Manifeste)
  • Container-Laufzeit: docker://19.3.12
  • Kubernetes-Version: v1.19.2
  • Kubernetes-Orchestrator: keiner
  • Kubernetes-aktivierte Feature-Gates: nur Kubernetes-Standardwerte
  • Betriebssystem: Flatcar Container Linux von Kinvolk 2605.6.0 (Oklo) 5.4.67-Flatcar
  • NetApp-Backend-Typen: ontap-san, ONTAP 9.7.0

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!

bug

Hilfreichster Kommentar

Schließen Sie dieses, da wir es nicht gesehen haben, seit wir unsere Netzwerkverbindungsgeschwindigkeit debuggt haben. Vielen Dank für die Hilfe! :))

Alle 4 Kommentare

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! :))

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen