Ein Health Check ist ein regelmäßiger Test, der feststellt, ob eine Service-Instanz korrekt arbeitet, typischerweise durch Aufruf eines HTTP-Endpoints, Aufbau einer TCP-Verbindung oder Ausführung eines Befehls. Orchestrierer und Load Balancer nutzen das Ergebnis, um fehlerhafte Instanzen neu zu starten oder keinen Traffic mehr an sie zu senden. Kubernetes setzt Health Checks als Liveness-, Readiness- und Startup-Probes um.
Was ein Health Check ist
Ein Health Check ist eine automatisierte Frage, die immer wieder gestellt wird: Ist diese Instanz in Ordnung? Fragesteller ist meist Infrastruktur, kein Mensch: ein Container-Orchestrierer, ein Load Balancer, ein Service Mesh oder ein externes Monitoring-System. Die Antwort löst automatische Aktionen aus. Eine fehlerhafte Instanz wird neu gestartet, aus der Rotation genommen oder ersetzt, oft bevor Nutzer etwas merken.
Health Checks gibt es in mehreren Varianten. Prozess-Checks prüfen, ob etwas läuft. Endpoint-Checks rufen einen HTTP- oder gRPC-Endpoint wie /healthz auf und erwarten einen Erfolgsstatus. Synthetische Checks laufen von außerhalb des Systems und durchlaufen einen echten Nutzerpfad. Jede Variante beantwortet eine etwas andere Frage, und wer sie verwechselt, riskiert Ausfälle.
Liveness-, Readiness- und Startup-Probes in Kubernetes
Kubernetes unterscheidet drei Probe-Typen mit jeweils unterschiedlicher Konsequenz bei einem Fehlschlag:
| Probe | Frage | Bei Fehlschlag |
|---|---|---|
| Liveness | Hängt der Container unrettbar fest? | Das Kubelet beendet den Container und startet ihn neu. |
| Readiness | Kann der Container gerade Traffic bedienen? | Der Pod wird aus den Service-Endpoints entfernt, bis er wieder bereit ist, aber nicht neu gestartet. |
| Startup | Ist die Anwendung fertig gestartet? | Liveness- und Readiness-Checks werden zurückgehalten, bis sie erfolgreich ist. Gelingt das nie, wird der Container neu gestartet. |
Jede Probe nutzt einen von vier Mechanismen: httpGet (jeder Status von 200 bis 399 gilt als Erfolg), tcpSocket, exec (Exit-Code 0 ist Erfolg) oder grpc mit dem Standardprotokoll für gRPC Health Checking. Das Timing steuern initialDelaySeconds, periodSeconds (Standard 10), timeoutSeconds (Standard 1), failureThreshold (Standard 3) und successThreshold (Standard 1).
Beispielkonfiguration
containers:
- name: api
image: example/api:1.4.2
startupProbe:
httpGet: { path: /livez, port: 8080 }
periodSeconds: 5
failureThreshold: 24 # bis zu 120 s für den Start
livenessProbe:
httpGet: { path: /livez, port: 8080 }
periodSeconds: 10
failureThreshold: 3
readinessProbe:
httpGet: { path: /readyz, port: 8080 }
periodSeconds: 5
failureThreshold: 2In diesem beispielhaften Setup prüft /livez nur, ob der Prozess antworten kann. /readyz verifiziert zusätzlich, dass Caches aufgewärmt sind und der Connection Pool zur primären Datenbank verfügbar ist. Ein langsamer Start löst keine Neustarts mehr aus, und ein vorübergehend überlasteter Pod fällt aus der Rotation, ohne beendet zu werden.
Warum Health Checks wichtig sind
Health Checks sind die Grundlage selbstheilender Systeme und sicherer Rollouts. Rolling Updates und Canary Deployments entscheiden anhand der Readiness, wann ein neuer Pod Traffic erhalten darf. Load Balancer, etwa Application Load Balancer in der Cloud, nutzen eigene Health Checks, um Traffic nur auf gesunde Ziele zu verteilen. Schlecht entworfene Checks können Probleme allerdings verstärken, statt sie einzudämmen.
Konventionen für Health-Endpoints
Kubernetes selbst stellt am API-Server /livez und /readyz bereit, und viele Frameworks folgen ähnlichen Konventionen. Spring Boot Actuator bietet zum Beispiel getrennte Health-Gruppen für Liveness und Readiness. Ein guter Health-Endpoint antwortet schnell, signalisiert den Zustand über Statuscodes statt nur über den Response-Body und kann optional in einem geschützten, ausführlichen Modus Details einzelner Prüfungen für Menschen ausgeben. Halten Sie diesen Vertrag stabil, denn Plattform-Teams, Load Balancer und Monitoring-Tools hängen davon ab.
Best Practices
- Liveness flach halten. Ein Liveness-Check sollte nur fehlschlagen, wenn ein Neustart tatsächlich hilft, etwa bei einem Deadlock. Datenbanken oder nachgelagerte Services gehören nicht in die Liveness.
- Readiness aussagekräftig gestalten. Readiness darf kritische lokale Abhängigkeiten einbeziehen. Vorsicht bei gemeinsam genutzten: Melden alle Pods bei einem kurzen Datenbank-Aussetzer „nicht bereit“, verschwindet der gesamte Service auf einmal.
- Startup-Probes für langsame Starter nutzen statt langer
initialDelaySeconds, die das Erkennen echter Fehler verzögern. - Checks günstig und schnell halten, deutlich innerhalb von
timeoutSeconds, und sie aus Request-Metriken und Logs herausfiltern, um Rauschen zu vermeiden. - Nicht allein auf interne Checks verlassen. Kombinieren Sie sie mit externem synthetischem Monitoring, das echte Nutzerpfade testet und die Verfügbarkeit misst.
Häufige Fehler
Der folgenreichste Fehler ist ein tiefer Liveness-Check. Wird eine gemeinsame Datenbank langsam, laufen die Liveness-Probes aller Pods in den Timeout, Kubernetes startet alle neu, und der Neustart-Sturm macht aus einer teilweisen Beeinträchtigung einen Totalausfall. Weitere Fehler sind der Standard-Timeout von einer Sekunde für einen Endpoint, der manchmal zwei braucht, Health-Endpoints, die unabhängig vom Zustand immer 200 liefern, und Checks, die aus dem Internet erreichbar sind und interne Details preisgeben.
Wie Obseria unterstützt
Das Kubernetes Monitoring von Obseria erfasst Probe-Fehlschläge, Neustarts und Readiness-Wechsel pro Workload und korreliert sie mit Deployments und Ressourcendruck. Synthetische Checks von über 50 Standorten testen Endpoints und Nutzerpfade von außen, die Ergebnisse können in Statusseiten einfließen. Siehe auch die Kubernetes-Observability-Checkliste.
