Viele geben beiden Sonden denselben Endpunkt und glauben, gut gerüstet zu sein. Dabei verursacht genau das die Neustartschleifen, die eine Anwendung in den Ausfall treiben.
Viele denken, Kubernetes brauche eine einzige Gesundheitsprüfung, denn gesund ist gesund. Plausibel klingt das, weil beide Sonden denselben HTTP-Aufruf machen, etwa GET /healthz mit Antwortcode 200 bis 399 als Erfolg.
Tatsächlich stellen die Sonden zwei verschiedene Fragen. Die Liveness-Probe (Lebenssonde) prüft, ob der Container überhaupt noch funktionsfähig ist oder durch einen Neustart repariert werden kann. Die Readiness-Probe (Bereitschaftsonde) prüft, ob er gerade Verkehr annehmen darf. Schlägt Readiness fehl, nimmt der Kubelet – der Agent auf jedem Knoten, der Container startet und überwacht – den Pod (die kleinste Einheit in Kubernetes) aus den Endpoints des Service; der Container läuft weiter, es kommt nur kein Verkehr mehr an.
Der Irrtum entsteht, weil beide Prüfungen technisch identisch aussehen. Was fehlt, ist die Frage nach der Folge: Neustart oder Pause.
Eine Anwendung lädt beim Start große Datenmengen und antwortet noch nicht. Wer hier Liveness mit Readiness gleichschaltet, startet den Container neu, obwohl er nur Zeit bräuchte. Noch schlimmer: Eine Liveness-Probe, die die externe Datenbank mitprüft, löst bei deren Ausfall eine Neustartschleife aus, die nichts behebt. Abhängigkeiten gehören deshalb in die Readiness-Probe.
Woran man es erkennt: Mit den Standardwerten gilt ein Container nach drei aufeinanderfolgenden Fehlversuchen im Abstand von zehn Sekunden als nicht gesund. Wer Container im Kreis drehen sieht, obwohl sie nur langsam starten, hat Liveness zu scharf gestellt.
Liveness heißt nicht „alles prüfen, was wichtig ist“, sondern „nur prüfen, was ein Neustart reparieren kann“.
📌 Liveness vs. Readiness · Kubelet · failureThreshold 3
📚 Cloud von Grund auf · Tag 4 von 30
#kubernetes #devops #sre
Viele denken, Kubernetes brauche eine einzige Gesundheitsprüfung, denn gesund ist gesund. Plausibel klingt das, weil beide Sonden denselben HTTP-Aufruf machen, etwa GET /healthz mit Antwortcode 200 bis 399 als Erfolg.
Tatsächlich stellen die Sonden zwei verschiedene Fragen. Die Liveness-Probe (Lebenssonde) prüft, ob der Container überhaupt noch funktionsfähig ist oder durch einen Neustart repariert werden kann. Die Readiness-Probe (Bereitschaftsonde) prüft, ob er gerade Verkehr annehmen darf. Schlägt Readiness fehl, nimmt der Kubelet – der Agent auf jedem Knoten, der Container startet und überwacht – den Pod (die kleinste Einheit in Kubernetes) aus den Endpoints des Service; der Container läuft weiter, es kommt nur kein Verkehr mehr an.
Der Irrtum entsteht, weil beide Prüfungen technisch identisch aussehen. Was fehlt, ist die Frage nach der Folge: Neustart oder Pause.
Eine Anwendung lädt beim Start große Datenmengen und antwortet noch nicht. Wer hier Liveness mit Readiness gleichschaltet, startet den Container neu, obwohl er nur Zeit bräuchte. Noch schlimmer: Eine Liveness-Probe, die die externe Datenbank mitprüft, löst bei deren Ausfall eine Neustartschleife aus, die nichts behebt. Abhängigkeiten gehören deshalb in die Readiness-Probe.
Woran man es erkennt: Mit den Standardwerten gilt ein Container nach drei aufeinanderfolgenden Fehlversuchen im Abstand von zehn Sekunden als nicht gesund. Wer Container im Kreis drehen sieht, obwohl sie nur langsam starten, hat Liveness zu scharf gestellt.
Liveness heißt nicht „alles prüfen, was wichtig ist“, sondern „nur prüfen, was ein Neustart reparieren kann“.
📌 Liveness vs. Readiness · Kubelet · failureThreshold 3
📚 Cloud von Grund auf · Tag 4 von 30
#kubernetes #devops #sre
1 Tag vor
