Ich habe eine Anwendung geerbt, die ich im Cluster als persistenten Pod bereitstellen muss, um Zugriff auf andere Ressourcen zu haben, die aber nur bei Bedarf ausgeführt wird, wenn ein Benutzer kubectl execden Pod betritt. Bei der Initialisierung muss sie nichts weiter tun, als den Pod für einen Benutzer verfügbar zu machen, der execzu einem späteren Zeitpunkt darauf zugreifen kann.
Dies funktioniert auf unserem alten Jenkins-X 2-Cluster einwandfrei, mit der neuen Version von Jenkinx-X 3 kommt es jedoch nicht voran.
Wenn es bereitgestellt wird, scheint der Status einen Lebenszyklus von
Running
Completed
CrashLoopBackOff
Zeigt jedoch kubectl logs -n <<namespace>> <<podname>> -pkeine Fehler, und in kubectl describe pod -n <<namespace>> <<podname>>dem Containers/<<appname>>Abschnitt enthält
State: Waiting
Reason: CrashLoopBackOff
Last State: Terminated
Reason: Completed
Exit Code: 0
CrashLoopBackoffDas sieht inkonsistent aus. Ich kann nicht erkennen, wie es zu einem letzten Zustand von Terminated„weil “ Completedund einem von 0 gekommen ist. Exit CodeSoweit ich sehen kann, schlägt die Anwendung nicht fehl. Es ist nur so, dass Kubernetes den Pod als abgeschlossen herunterfährt, anstatt ihn laufen zu lassen, und er bleibt dann irgendwie in CrashLoopBackoff hängen.
Ich hatte mich gefragt, ob dies etwas mit Bereitschafts- oder Aktivitätsprüfungen zu tun hatte, die das System beendeten, weil kein dauerhaft laufender Prozess zum Bearbeiten einer Anforderung gefunden wurde. Das Entfernen dieser Prüfungen oder die Rückkehr zu älteren Versionen scheint jedoch keinen Unterschied zu machen.
Vermutlich ist in den Diagrammen zwischen der alten und der neuen Version etwas schiefgelaufen, aber mir gehen die Ideen aus, wo ich suchen soll. Gibt es jemanden, der etwas vorschlagen kann, was die Ursache sein könnte?