Die restartPolicy ist ein Feld der PodSpec und legt fest, ob Kubernetes einen beendeten Container im selben Pod erneut startet. Erlaubt sind Always, OnFailure und Never; der Standardwert ist Always.
Die drei Werte
- Always: Der Container wird nach jedem Beenden neu gestartet — auch nach einem erfolgreichen Ende mit Exit-Code 0. Typisch für langlebige Dienste.
- OnFailure: Ein Neustart erfolgt nur bei einem Fehler, also bei einem Exit-Code ungleich 0. Endet der Container sauber, bleibt er beendet.
- Never: Kubernetes startet den Container nie neu; er bleibt in seinem Endzustand stehen.
Backoff statt Dauerstart
Scheitert ein Container immer wieder, wartet das Kubelet vor jedem neuen Versuch länger: Die Verzögerung verdoppelt sich (10, 20, 40 Sekunden und so weiter) und ist bei fünf Minuten gedeckelt. Diesen Zustand zeigt kubectl get pods als CrashLoopBackOff; nach etwa zehn Minuten fehlerfreien Laufs wird der Backoff zurückgesetzt.
Container neu starten heißt nicht Pod neu bauen
Die restartPolicy wirkt nur innerhalb des bestehenden Pods: Name, IP-Adresse und Volumes bleiben erhalten, nur der Container-Prozess wird ersetzt. Ein ganz neuer Pod mit neuer IP entsteht erst, wenn ein Controller wie ein Deployment oder StatefulSet den Pod ersetzt. Den Zähler der Neustarts liefert .status.containerStatuses[].restartCount.
Besonderheiten bei Jobs und Init-Containern
Für Jobs und CronJobs ist Always nicht zulässig — ein Job muss ja enden können; dort stehen Never oder OnFailure. Reguläre Init-Container folgen der restartPolicy des Pods, während nativ eingebundene Sidecar-Container als Init-Container mit restartPolicy: Always über die gesamte Pod-Lebensdauer laufen.
Abgrenzung
Die restartPolicy entscheidet nur über Wiederholungen. Wie der Pod selbst durch seine Lifecycle-Phasen wandert, beschreibt der Pod-Lifecycle; Aktionen beim Start und vor dem Beenden übernehmen Lifecycle Hooks.
Verwandte Grundlagen: Liveness Probe, kubectl-Befehle.