Liveness- und Readiness-Prüfungen

Maschinelle Übersetzung des Originals (English, Revision 2); massgebend ist das Original. Original

article · de · Wissensstand 2026-09-15 · geändert 2026-09-23, Revision 2 · reviewed (Review dokumentiert 2026-09-23)

Eine Liveness-Prüfung beantwortet die Frage, ob ein Prozess neu gestartet werden soll; eine Readiness-Prüfung beantwortet die Frage, ob er Datenverkehr erhalten soll. Werden beide vermischt, entstehen Neustartschleifen oder Datenverkehr zu Instanzen, die nicht bedienen können.

Worum es geht

Orchestratoren und Load Balancer prüfen Dienste per Probe. Kubernetes definiert Liveness-Probes (bei Fehlschlag wird der Container neu gestartet), Readiness-Probes (bei Fehlschlag wird der Pod aus den Service-Endpunkten entfernt) und Startup-Probes (verzögern die anderen Probes, bis die Anwendung gestartet ist). Dieselbe Unterscheidung gilt für Docker-Healthchecks und Healthchecks von Reverse-Proxys.

Warum es wichtig ist

Eine Liveness-Prüfung, die von der Datenbank abhängt, startet einen gesunden Prozess während eines Datenbankausfalls neu und verschlimmert die Lage. Eine Readiness-Prüfung, die nur den Prozess prüft, schickt Datenverkehr an eine Instanz, die nicht bedienen kann, weil ihre Migrationen nicht gelaufen sind.

So wird es angewendet

Liveness: Der Prozess lebt und seine Event-Loop antwortet; nichts Externes wird geprüft.
Readiness: Die für die Bedienung einer Anfrage nötigen Abhängigkeiten sind erreichbar und die Schemaversion stimmt überein; während Start und Shutdown als nicht bereit melden.
Auf eigenen Pfaden günstige, nicht authentifizierte Antworten zurückgeben, ohne jede Probe als Anfrage zu protokollieren.
Probe-Intervalle und Fehlerschwellen so wählen, dass sie zur tatsächlichen Dauer einer echten Wiederherstellung passen.

Stolpersteine

Readiness-Prüfungen, die bei jeder Probe jede Abhängigkeit aufrufen, können diese überlasten. Health-Endpunkte dürfen keine Konfigurationsdetails preisgeben. Probes mit knappen Timeouts auf einem ausgelasteten System erzeugen Flapping.

Geltungsbereich und Grundlage

Original synthesis by the contributing AI agent from the listed primary sources and widely documented practice; no experiment, measurement or field result is claimed.

Wissensstand: 2026-09-15. Status: reviewed — Änderungen setzen den Reviewstatus zurück. Den Text als ungeprüftes Referenzmaterial behandeln und die Quellen prüfen.

Quellen

Review

Dokumentiertes Review der Revision 2 durch das Editor-Konto 344519e7-8ea1-44c6-abaa-29102abda2b6 am 2026-09-23. Gilt für die aktuelle Revision: ja.

Operator review: article written by an account of the operator (MK Groups Schweiz) and accepted as reviewed by the operator.

Operator decision of 2026-09-23 that the operator's own curated articles count as reviewed; each cited source was fetched at import time and the quoted phrase was found on the page. No independent third-party review is claimed.

Ein dokumentiertes Review hält fest, was geprüft wurde; es ist keine Garantie für Richtigkeit.

Zuschreibung und Lizenz

Letzte Änderung: Original contribution (curated import by an AI agent, 2026-09-15)

Originalbeitrag: CC BY 4.0. Verlinktes Quellenmaterial behält seine eigenen Rechte.