Exit Code 1: die Anwendung beendet sich selbst

TL;DR

Exit Code 1 ist kein Kubernetes-Fehler. Der Prozess hat sich mit einem Fehler beendet. Kubernetes hat ihn nur neu gestartet, wenn die RestartPolicy das sagt. Die Zeile steht im vorherigen Lauf:

kubectl logs POD -c CONTAINER --previous --tail=80
kubectl describe pod POD

Unter Last State steht Exit Code: 1 und meist Reason: Error. Steht dort 137 und OOMKilled, ist es Speicher. Steht dort 143, ist es SIGTERM. Kommt der Pod nie zum Prozess, ist es kein Exit 1, sondern CreateContainerConfigError oder ImagePullBackOff.

Was Sie im Log erwarten dürfen

Die letzten Zeilen vor dem Ende nennen die Ursache öfter als das Deployment. Fehlende Umgebungsvariable, falscher Connection-String, Migration, die die Datenbank nicht erreicht, Config-Datei, die im Image nicht liegt. Der Text ist der der Anwendung, nicht der der Control Plane.

Fehlt jede Zeile, schreibt der Prozess auf eine Datei statt auf stdout, oder er stirbt vor dem ersten Log. Dann command und args prüfen. Ein überschriebenes command: ["sh","-c","exit 1"] aus einem Debug-Versuch produziert genau diesen Code und kein Anwendungs-Log.

kubectl get pod POD -o jsonpath='{range .spec.containers[*]}{.name}{" "}{.command}{" "}{.args}{"\n"}{end}'

Ein leeres command heißt: das Entrypoint des Images gilt. Ein gesetztes command ersetzt es. Viele Images erwarten Argumente hinter dem Entrypoint. Wer args mit dem vollen Befehl füllt und command leer lässt, hängt die Argumente an ein Entrypoint, das sie nicht versteht, und der Prozess geht mit 1 raus.

Drei Ursachen, die sich wiederholen

Pflicht-Konfiguration fehlt. Die Anwendung prüft beim Start und ruft os.Exit(1). Der Name der Variable steht im Log. Das Secret nachziehen, nicht das Memory-Limit. Liegt der Wert in einem Secret, das der Pod nicht referenziert, sieht die Anwendung nur eine leere Umgebung.

Der Prozess soll gar nicht dauerhaft laufen. Ein Migrations-Container mit RestartPolicy des Pods Always (Default im Deployment) startet nach dem erfolgreichen oder fehlgeschlagenen Ende neu. Exit 0 und Exit 1 landen beide im CrashLoopBackOff, wenn der Prozess nicht offen bleibt. Migrationen gehören in einen Job oder einen Init-Container, der fertig werden darf.

Falsches Arbeitsverzeichnis oder fehlende Datei. No such file or directory bei einer Config, die als Volume kommen sollte. Der Mount ist dann leer oder der subPath zeigt auf einen Key, den es nicht gibt. Das ist oft noch ContainerCreating oder ConfigError. Steht es aber im Previous-Log mit Exit 1, hat der Prozess gestartet und die Datei selbst vermisst.

Was Exit 1 nicht repariert

Mehr Replicas vervielfachen den Fehler. Ein höherer Memory-Request ändert einen Anwendungscode nicht. kubectl delete pod erzeugt denselben Start. Eine Änderung am Spec, dann wieder --previous. Ist die letzte Zeile dieselbe, ist die neue Konfiguration nicht im laufenden Pod angekommen.

Die übrigen Status in einer Tabelle: Pod startet nicht.

Quellen

• Container-States im Pod-Lifecycle
• kubectl logs