Trident: Kehrt nicht zurück, nachdem „Fehler bei der Identifizierung des Update-Szenarios“ protokolliert wurde.

Hallo @takuhiro ,

Vielen Dank für diese Anfrage.
Wenn currentInstalledTridentVersion und tridentK8sConfigVersion nicht von bestehenden Deployments oder Daemonsets abgerufen werden, bedeutet dies, dass etwas nicht stimmt, z. Irgendwas stimmt nicht.

Eine ideale Sache wäre, diese Objekte neu zu erstellen. Jetzt gibt es hier zwei leere Variablen:

1. tridentK8sConfigVersion , wenn dies leer zurückgegeben wird, kann Trident nicht erkennen, ob es sich um ein Upgrade-Szenario handelt oder nicht. In diesem Szenario ist Ihre Trident-Installation also nicht für ein Upgrade markiert ( hier ).
2. currentInstalledTridentVersion , diese Variable wird zum Setzen der Version im CR-Status verwendet und genau einmal in der installer.go verwendet, um die vorhandene Dreizack-Version mit der vom Bild angebotenen Version des Dreizacks zu vergleichen ( hier ). In diesem Szenario sollte diese Bedingung fehlschlagen und Trident für die Neuinstallation markieren.

Die Erwartung hier ist, dass die Neuinstallation die Bereitstellung und das Daemonset selbst reparieren würde, sodass in der nächsten Iteration Versionsinformationen ordnungsgemäß abgerufen werden können.

@ntap-arorar Vielen Dank für die ausführliche Antwort. Ich habe die Logik verstanden, wenn tridentK8sConfigVersion und currentInstalledTridentVersion leer sind, und das würde in der nächsten Iteration behoben werden.

In unserem Fall war die vollständige Fehlermeldung dies. (Es tut mir leid, ich hätte zuerst den Kontext einfügen sollen.)

time="2021-06-26T14:56:52Z" level=error msg="Error identifying update scenario." controllingCR=trident err="unable to get list of deployments"

Hier wurde der Fehler unable to get list of deployments gemacht. Die Hauptursache des Fehlers war wahrscheinlich ein temporärer GET-Anforderungsfehler an api-server here , der zu einer unnötigen Neuinstallation führen könnte. In diesem Fall denke ich, dass es besser wäre, zurückzukehren und es in der nächsten Iteration erneut zu versuchen.

Ich glaube, dass es einen Spielraum gibt, diese Logik widerstandsfähiger gegen unbeabsichtigte Neuinstallationen aufgrund vorübergehender Probleme (falsch positiv) in der Kubernetes-Umgebung zu machen. Dies hängt vom zurückgegebenen Fehlertyp ab, da der Operator es sonst versäumt, echte Trident-Installationen zu reparieren, die sich in einem schlechten Zustand befinden.

Ich stimme zu, dass der Fehler vom Fehlertyp behandelt werden sollte. Wenn der Fehlertyp vorübergehende Probleme darstellt, kann der Controller die Neuinstallation überspringen, da der Fehler in der nächsten Iteration bald behoben würde.

Dieses Problem wird mit Commit bf43f8 behoben und ist in Trident 21.10.0 enthalten.