Liveness, Readiness, Startup Probes konfigurieren

TL;DR

• Liveness Probes starten Container neu, wenn die Anwendung hängt - nicht für langsame Starts verwenden
• Readiness Probes steuern, ob ein Pod Traffic erhält - ideal für Abhängigkeiten wie Datenbanken
• Startup Probes schützen langsam startende Container vor vorzeitigen Neustarts durch Liveness Probes
• Drei Methoden: HTTP GET, TCP Socket und Exec-Kommando - HTTP ist der Standard für Webservices
• Häufigster Fehler: Liveness Probe zu aggressiv konfiguriert, sodass gesunde Pods gekillt werden

Warum Health Checks in Kubernetes?

Kubernetes überwacht Container standardmäßig nur auf Prozessebene. Stürzt der Hauptprozess ab, wird der Container neu gestartet. Aber was passiert bei einem Deadlock, einer vollen Connection-Queue oder einem OOM im Subprocess? Der Prozess läuft, die Anwendung ist tot.

# Pod ohne Probes - Kubernetes sieht nur den Prozess
apiVersion: v1
kind: Pod
metadata:
  name: web-ohne-probes
spec:
  containers:
    - name: app
      image: myapp:1.0
      ports:
        - containerPort: 8080
      # Kein Health Check - gefährlich in Produktion!

Health Check Probes lösen dieses Problem. Sie prüfen den tatsächlichen Zustand der Anwendung.

Die drei Probe-Typen

Liveness Probe: Ist die Anwendung noch am Leben?

Die Liveness Probe prüft, ob der Container funktioniert. Schlägt sie fehl, wird der Container neu gestartet. Das ist das stärkste Mittel - ein Neustart killt laufende Requests.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: app
          image: myapp:1.0
          ports:
            - containerPort: 8080
          livenessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 15
            periodSeconds: 10
            failureThreshold: 3
            timeoutSeconds: 3

Der Endpunkt /healthz sollte nur prüfen, ob die Anwendung grundsätzlich antwortet. Keine Datenbank-Checks hier - sonst wird der Pod bei einem DB-Ausfall endlos neu gestartet.

Readiness Probe: Kann der Pod Traffic verarbeiten?

Die Readiness Probe bestimmt, ob ein Pod in den Service-Endpunkt aufgenommen wird. Schlägt sie fehl, bekommt der Pod keinen Traffic mehr, wird aber nicht neu gestartet.

readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 5
  failureThreshold: 3
  successThreshold: 2

Der /ready-Endpunkt darf Abhängigkeiten prüfen: Datenbank erreichbar? Cache warm? Migrations abgeschlossen? Ein Pod der nicht ready ist, schadet niemandem.

Startup Probe: Schutz beim Hochfahren

Java-Anwendungen, ML-Modelle oder Legacy-Systeme brauchen oft 30-120 Sekunden zum Starten. Ohne Startup Probe müsste initialDelaySeconds der Liveness Probe extrem hoch gesetzt werden.

startupProbe:
  httpGet:
    path: /healthz
    port: 8080
  failureThreshold: 30
  periodSeconds: 5
  # Gibt der App 30 × 5 = 150 Sekunden zum Starten

Solange die Startup Probe läuft, sind Liveness und Readiness Probes deaktiviert. Erst nach erfolgreichem Startup greifen die anderen Probes.

Probe-Methoden im Vergleich

HTTP GET Probe

Die häufigste Variante. Jeder HTTP-Statuscode zwischen 200 und 399 gilt als Erfolg.

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
    httpHeaders:
      - name: X-Health-Check
        value: kubernetes

TCP Socket Probe

Prüft nur, ob der Port offen ist. Gut für Dienste ohne HTTP-Endpunkt.

livenessProbe:
  tcpSocket:
    port: 3306
  periodSeconds: 15

Exec Probe

Führt ein Kommando im Container aus. Exit-Code 0 bedeutet Erfolg.

livenessProbe:
  exec:
    command:
      - cat
      - /tmp/healthy
  periodSeconds: 10

Timing-Parameter richtig setzen

Die Timing-Parameter entscheiden, ob Probes helfen oder schaden.

Praxisbeispiel für eine typische Spring-Boot-Anwendung:

containers:
  - name: spring-app
    image: spring-app:2.0
    startupProbe:
      httpGet:
        path: /actuator/health
        port: 8080
      failureThreshold: 30
      periodSeconds: 5
    livenessProbe:
      httpGet:
        path: /actuator/health/liveness
        port: 8080
      periodSeconds: 15
      failureThreshold: 3
      timeoutSeconds: 5
    readinessProbe:
      httpGet:
        path: /actuator/health/readiness
        port: 8080
      periodSeconds: 5
      failureThreshold: 3
      successThreshold: 2

Häufige Fehler vermeiden

Fehler 1: Liveness Probe prüft externe Abhängigkeiten

# FALSCH - Pod wird bei DB-Ausfall endlos neu gestartet
livenessProbe:
  httpGet:
    path: /health/full  # prüft DB, Redis, S3...
    port: 8080

Wenn die Datenbank ausfällt, sind alle Pods betroffen. Neustarts helfen nicht und machen es schlimmer, weil die Reconnection-Logik von vorne beginnt.

Lösung: Liveness prüft nur den Prozess selbst. Readiness prüft Abhängigkeiten.

Fehler 2: Zu aggressive Timing-Parameter

# FALSCH - Pod hat nur 3 Sekunden Reaktionszeit
livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  periodSeconds: 1
  failureThreshold: 3
  timeoutSeconds: 1

Bei kurzen GC-Pausen oder CPU-Throttling im Cluster schlägt diese Probe fehl, obwohl die Anwendung gesund ist. Das Ergebnis: Pods werden ständig neu gestartet, was die Situation verschlimmert.

Fehler 3: Keine Startup Probe bei langsamen Anwendungen

Ohne Startup Probe muss initialDelaySeconds den Worst-Case-Start abdecken. Das verzögert die Fehlererkennung nach einem echten Absturz um genau diese Zeit.

Debugging von Probe-Fehlern

# Events prüfen - zeigt Probe-Failures
kubectl describe pod <pod-name> | grep -A 5 "Events"

# Probe manuell testen
kubectl exec <pod-name> -- curl -s localhost:8080/healthz

# Logs bei Restarts analysieren
kubectl logs <pod-name> --previous

FAQ

Was ist der Unterschied zwischen Liveness und Readiness Probe?

Liveness prüft, ob der Container neu gestartet werden muss. Readiness prüft, ob der Pod Traffic empfangen soll. Liveness-Failure führt zum Restart, Readiness-Failure entfernt den Pod nur aus dem Service-Endpunkt.

Brauche ich alle drei Probe-Typen?

Nicht zwingend. Readiness Probe ist fast immer sinnvoll. Liveness Probe brauchen Sie bei Anwendungen, die in Deadlocks geraten können. Startup Probes nur bei langen Startzeiten über 10-15 Sekunden.

Warum wird mein Pod ständig neu gestartet?

Prüfen Sie mit kubectl describe pod die Events. Häufigste Ursache: Liveness Probe schlägt fehl, bevor die Anwendung fertig gestartet ist. Lösung: Startup Probe hinzufügen oder initialDelaySeconds erhöhen.

Welche Probe-Methode soll ich verwenden?

HTTP GET für Webservices, TCP Socket für Datenbanken und Dienste ohne HTTP, Exec für komplexe Checks die ein Skript erfordern. HTTP ist in 90% der Fälle die richtige Wahl.

Wie teste ich Probes lokal?

Starten Sie den Container mit docker run und rufen Sie den Health-Endpunkt mit curl auf. In Minikube oder kind können Sie die Probe-Konfiguration testen und mit kubectl describe pod die Ergebnisse prüfen.