Eine Kubernetes Liveness Probe prüft laufend, ob eine Anwendung noch richtig arbeitet, und lässt Kubernetes den Container neu starten, wenn die Prüfung wiederholt fehlschlägt. Eine Readiness Probe entscheidet dagegen nicht über einen Neustart, sondern darüber, ob ein Pod Traffic vom Service erhalten darf. Beide zusammen sind die Grundlage für Self Healing in Kubernetes, ohne dass jemand nachts ans Telefon muss.
Ich betreibe Kubernetes-Cluster in Produktion und habe den Probes im achten Kapitel meines Kubernetes-Praxisbuchs bei Rheinwerk einen eigenen Abschnitt gewidmet. Falsch konfigurierte Probes gehören zu den häufigsten Ursachen für Ausfälle, die ich in Kundenclustern gesehen habe, meist weil eine Probe zu viel oder zu früh prüft. Alle meine Beiträge zu Kubernetes findest du gesammelt auf der Seite Kubernetes.
Kubernetes Liveness Probe, Readiness Probe und Startup Probe: drei Fragen an deinen Pod
Die drei Probe-Typen beantworten unterschiedliche Fragen und lösen unterschiedliche Aktionen aus. Die Liveness Probe fragt: Funktioniert die Anwendung noch? Schlägt sie über einen definierten Zeitraum fehl, startet Kubernetes den Container neu, gesteuert über die Restart Policy des Pods.
Die Readiness Probe fragt: Ist die Anwendung gerade bereit, Anfragen zu verarbeiten? Schlägt sie fehl, nimmt der zugehörige Service den Pod aus dem Load Balancing heraus, ohne den Container neu zu starten. Das ist nicht nur beim Start nützlich, sondern auch, wenn eine laufende Anwendung kurzzeitig überlastet ist und lieber keine neuen Anfragen annehmen möchte.
Die Startup Probe fragt: Ist der Container überhaupt fertig hochgefahren? Solange sie nicht erfolgreich war, sind Liveness und Readiness Probe deaktiviert. Das schützt Anwendungen mit langem Start davor, als hängend eingestuft und vorzeitig neu gestartet zu werden. Bei mir kommt sie fast nur bei Legacy-Anwendungen mit mehrminütigem Hochfahren zum Einsatz, moderne Anwendungen brauchen sie selten.
Mechanismen: HTTP, TCP, Exec und gRPC
Jede Probe braucht eine Methode, mit der sie den Zustand deiner Anwendung abfragt. Am häufigsten ist die HTTP-Probe: Kubernetes sendet einen GET-Request an einen Port und Pfad deiner Wahl, und jeder Statuscode zwischen 200 und 399 gilt als Erfolg. Das gibt dir die größte Freiheit, weil du den Health-Endpunkt selbst gestaltest.
Kann deine Anwendung kein HTTP sprechen, etwa eine Datenbank oder eine Queue, prüft eine TCP-Probe nur, ob sich ein Socket auf dem angegebenen Port öffnen lässt. Die Exec-Probe führt stattdessen einen Befehl im Container aus und wertet den Exit-Code aus, praktisch für Anwendungen, die ihren Zustand nur über eine lokale Datei oder ein Kommandozeilenwerkzeug preisgeben. Seit einigen Kubernetes-Releases steht zusätzlich eine gRPC-Probe zur Verfügung, für Dienste, die ohnehin über gRPC sprechen.
Die Parameter, die über Fehlalarme entscheiden
Eine Probe ist nur so gut wie ihre Zeitwerte. Fünf Parameter bestimmen, wie streng und wie geduldig Kubernetes prüft:
| Parameter |
Bedeutung |
Standardwert |
| initialDelaySeconds |
Wartezeit, bevor die erste Probe überhaupt läuft |
0 |
| periodSeconds |
Abstand zwischen zwei Prüfungen |
10 |
| timeoutSeconds |
wie lange eine einzelne Prüfung auf Antwort wartet |
1 |
| failureThreshold |
wie viele Fehlschläge hintereinander nötig sind, bis die Probe als fehlgeschlagen gilt |
3 |
| successThreshold |
wie viele Erfolge hintereinander nötig sind, bis eine Readiness Probe wieder als erfolgreich gilt (bei Liveness und Startup fest auf 1) |
1 |
Ein zu niedriger timeoutSeconds-Wert ist eine der häufigsten Ursachen für eine Readiness Probe Timeout, gerade wenn deine Anwendung unter Last kurz langsamer antwortet als sonst. Bewährt hat sich, Liveness und Readiness Probe auf denselben Endpunkt zu legen, die Readiness Probe aber mit kürzerer Periode oder kleinerem failureThreshold zu fahren: So wechselt ein Pod erst in den Not-Ready-Zustand und wird aus dem Load Balancing genommen, bevor die strengere Liveness Probe ihn neu startet. Das ist Praxis, keine Kubernetes-Vorgabe, und es gibt einen Fall, in dem getrennte Endpunkte klar sicherer sind: Sobald der Endpunkt auch Abhängigkeiten prüft, etwa die Datenbank, darf die Liveness Probe ihn nicht nutzen. Sonst startet Kubernetes bei einer kurz nicht erreichbaren Datenbank alle Pods gleichzeitig neu, obwohl die Anwendung selbst gesund ist. Dann gehört an die Liveness Probe ein Endpunkt, der ausschließlich den eigenen Prozess prüft, und an die Readiness Probe der mit den Abhängigkeiten.
Health-Endpunkte richtig bauen
Der größte Designfehler bei Probes ist, zu viel zu prüfen. Eine Liveness Probe soll ausschließlich beantworten, ob der eigene Prozess noch funktioniert, nicht ob eine Datenbank oder ein externer Dienst erreichbar ist. Prüft deine Liveness Probe eine Abhängigkeit mit, die gerade selbst Probleme hat, startet Kubernetes reihenweise gesunde Container neu und verwandelt einen Ausfall in eine Kaskade.
Für die Readiness Probe gilt das Gegenteil: Hier darfst und solltest du prüfen, ob alles vorhanden ist, was deine Anwendung zum Verarbeiten von Anfragen braucht, etwa eine offene Datenbankverbindung oder ein gefüllter Cache. Kannst du deine Anwendung selbst so bauen, dass sie sich bei einem nicht behebbaren Fehler mit einem Fehlercode beendet, brauchst du an der Stelle unter Umständen gar keine Liveness Probe und überlässt die Reaktion der Restart Policy des Pods.
Ein einfaches Beispiel für ein Manifest mit allen drei Probe-Typen an unterschiedlichen Endpunkten:
readinessProbe:
httpGet:
path: /readyz
port: 8080
initialDelaySeconds: 5
periodSeconds: 5
timeoutSeconds: 2
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 15
periodSeconds: 10
failureThreshold: 3
startupProbe:
httpGet:
path: /healthz
port: 8080
failureThreshold: 30
periodSeconds: 10
Die Startup Probe erlaubt hier bis zu fünf Minuten für den Start, bevor die Liveness Probe überhaupt zu zählen beginnt. /readyz prüft die Abhängigkeiten der Anwendung, /healthz nur den Prozess selbst, ein bewusst einfacher Endpunkt ohne externe Aufrufe.
Die drei Fehler, die zu Ausfällen führen
Der erste und häufigste Fehler ist eine zu strenge Liveness Probe: kurze Netzwerk-Hänger führen zu Neustarts, obwohl die Anwendung eigentlich gesund ist. Das zeigt sich oft als „Liveness probe failed: connection refused" in den Events, während die Anwendung selbst noch lief, aber unter kurzzeitiger Last nicht rechtzeitig antworten konnte. Ein höherer failureThreshold oder ein größeres periodSeconds entschärft das, ohne die Probe wirkungslos zu machen.
Der zweite Fehler ist eine Liveness Probe, die Abhängigkeiten mitprüft, wie im Abschnitt zu den Health-Endpunkten beschrieben. Der dritte Fehler ist eine fehlende Startup Probe bei Anwendungen mit langsamem Start: Ohne sie zählt die normale Liveness Probe schon während der Initialisierung mit und startet den Container neu, bevor er überhaupt fertig hochgefahren ist, der Pod hängt dann in einer Neustartschleife fest.
Häufige Fragen
Was ist der Unterschied zwischen Liveness und Readiness Probe?
Die Liveness Probe entscheidet, ob Kubernetes einen Container neu startet. Die Readiness Probe entscheidet, ob ein Pod Traffic vom Service erhält, ohne dass dabei etwas neu gestartet wird. Beide können auf demselben Endpunkt laufen, aber mit unterschiedlicher Strenge.
Wann brauche ich eine Startup Probe?
Vor allem bei Anwendungen mit langem, unvorhersehbarem Start, etwa Legacy-Software, die mehrere Minuten zum Hochfahren braucht. Moderne, schnell startende Anwendungen kommen in den meisten Fällen ohne Startup Probe aus.
Warum bekomme ich „Liveness probe failed: connection refused"?
Meist, weil die Anwendung zum Zeitpunkt der Prüfung kurzzeitig nicht antwortet, etwa wegen eines Netzwerk-Hängers, einer kurzen Garbage-Collection-Pause oder weil sie noch nicht vollständig gestartet ist. Ein zu niedriges initialDelaySeconds oder ein zu strenger failureThreshold verstärkt das Problem zusätzlich.
Was tue ich bei einer Readiness Probe Timeout?
Prüfe zuerst timeoutSeconds: Antwortet deine Anwendung unter Last langsamer als dieser Wert, gilt die Probe schon als fehlgeschlagen, obwohl die Anwendung nur beschäftigt ist. Ein realistischerer Timeout, gemessen unter echter Last, behebt das meist ohne weitere Änderungen.
Darf die Liveness Probe die Datenbank prüfen?
Nein, jedenfalls nicht direkt. Prüft die Liveness Probe eine Abhängigkeit, die selbst gerade Probleme hat, startet Kubernetes gesunde Container neu, ohne dass das etwas löst. Abhängigkeiten gehören in die Readiness Probe, die Liveness Probe soll nur den eigenen Prozess prüfen.
Wie du weitermachst
Probes hängen eng mit den Ressourcen zusammen, die du deinem Pod gibst: Ein gedrosselter Container erzeugt dieselben Symptome wie eine falsch konfigurierte Probe, und wie du die passenden Werte findest, steht in Kubernetes Requests und Limits erklärt. Landet ein Pod trotz richtiger Probes in einer Neustartschleife, hilft die systematische Fehlersuche in CrashLoopBackOff: Pods richtig debuggen. Und wie Probes beim Rollout einer neuen Version über den Zeitpunkt des Traffic-Wechsels entscheiden, steht in Kubernetes Deployment: Rollout erklärt.
Mein Vorschlag für heute: Öffne eines deiner Deployments und prüfe, ob Liveness und Readiness Probe denselben Endpunkt mit unterschiedlichem failureThreshold nutzen oder ob eine Probe versehentlich Abhängigkeiten mitprüft. Die vollständige Parameterliste findest du in der Kubernetes-Dokumentation zu Probes.
Ausführlich mit Beispielanwendung, Docker-Image und Testaufbau steht das in Kapitel 8 meines Kubernetes-Praxisbuchs bei Rheinwerk.
