Was sind liveness-, readiness- und startup-Probes, und wann verwendest du welche?

Question

IT Interview Practice · Accepted Answer

Probes lassen den kubelet die Gesundheit eines Containers prüfen und auf das Ergebnis reagieren. Es gibt drei: **liveness** (lebt er, oder sollte er neu gestartet werden?), **readiness** (ist er bereit, Traffic zu empfangen?) und **startup** (hat er das Hochfahren schon abgeschlossen?). Jede beantwortet eine andere Frage.

## Die drei Probes auf einen Blick

```text
LIVENESS   → "Hängt/deadlockt die App?"          FAIL → kubelet STARTET den Container NEU
READINESS  → "Kann sie jetzt Traffic bedienen?"   FAIL → Pod aus den Service-Endpunkten entfernt
                                                          (NICHT neu gestartet)
STARTUP    → "Ist der langsame Boot fertig?"       läuft ZUERST; währenddessen werden liveness &
                                                    readiness zurückgehalten
```

## Readiness vs. liveness — die zentrale Unterscheidung

```text
Readiness steuert TRAFFIC:
  → ein Pod, der readiness nicht besteht, wird AUS dem Service-Load-Balancer genommen,
    läuft aber weiter (z. B. wärmt er einen Cache oder eine Abhängigkeit ist down)
Liveness steuert LEBEN:
  → ein Pod, der liveness nicht besteht, wird GETÖTET und neu gestartet (irreparabel kaputt)
Liveness dort zu nutzen, wo du readiness meintest, verursacht unnötige restart loops.
```

## Probe-Definitionen

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      ports: [{ containerPort: 8080 }]

startupProbe:            # gibt einem langsamen Starter Zeit, bevor andere greifen
        httpGet: { path: /healthz, port: 8080 }
        failureThreshold: 30   # 30 * 10s = bis zu 5 Min zum Starten
        periodSeconds: 10

readinessProbe:          # Traffic steuern
        httpGet: { path: /ready, port: 8080 }
        initialDelaySeconds: 5
        periodSeconds: 10

livenessProbe:           # neu starten, wenn ungesund
        httpGet: { path: /healthz, port: 8080 }
        periodSeconds: 10
        failureThreshold: 3
```

## Probe-Mechanismen

```text
httpGet    → GET auf einen Pfad; 2xx/3xx = bestanden   (am häufigsten für Web-Apps)
tcpSocket  → können wir eine TCP-Verbindung öffnen?      (für Nicht-HTTP-Services)
exec       → einen Befehl ausführen; exit 0 = bestanden  (eigene Prüfungen)
grpc       → nativer gRPC health check
Wichtige Stellschrauben: initialDelaySeconds, periodSeconds, timeoutSeconds,
           failureThreshold, successThreshold.
```

## Warum es startup-Probes gibt

```text
Langsam startende Apps (JVM-Warmup, große Migrationen) zwangen dich früher zu einem riesigen
initialDelaySeconds bei liveness — was dann echte Abstürze langsam erkennbar machte.
Die startupProbe behebt das: sie schützt den langsamen Boot, und ERST nachdem sie besteht,
beginnen liveness/readiness mit ihren normalen (engen) Zeiten.
```

```bash
kubectl describe pod app     # probe-Fehler & Restart-Gründe in Events ansehen
kubectl get pod app          # READY-Spalte spiegelt readiness; RESTARTS spiegelt liveness
```

## Warum es wichtig ist

Health Probes sind die Art, wie Kubernetes self-healing und sicheres Traffic-Routing liefert, daher ist das Verständnis der drei Typen und wann man welchen verwendet essenzielles Zuverlässigkeitswissen. Die entscheidende Unterscheidung — eine, die viele Ingenieure stolpern lässt — ist die zwischen **readiness** und **liveness**: readiness steuert **Traffic** (ein fehlschlagender Pod wird aus dem Service-Load-Balancer genommen, läuft aber weiter, ideal, wenn er hochfährt oder eine Abhängigkeit vorübergehend down ist), während liveness **Leben** steuert (ein fehlschlagender Pod wird getötet und neu gestartet, für den Fall, dass er irreparabel deadlockt ist). Die beiden zu verwechseln — eine liveness probe dort zu nutzen, wo readiness gemeint war — verursacht unnötige restart loops und Ausfälle, daher ist das Wissen, welche Frage jede Probe beantwortet, direkt praktisch. Die **startup** probe löst einen echten historischen Schmerz: langsam bootende Apps erzwangen einst riesige `initialDelaySeconds` bei liveness (was die Erkennung echter Abstürze verzögerte), während eine startup probe das Boot-Fenster schützt und liveness/readiness erst mit engen, normalen Zeiten laufen lässt, sobald der Start erfolgreich ist. Die Probe-Mechanismen (`httpGet`, `tcpSocket`, `exec`, `grpc`) und die Stellschrauben (`initialDelaySeconds`, `periodSeconds`, `failureThreshold` usw.) zu verstehen, lässt dich Health-Checking korrekt konfigurieren statt per Rätselraten. Da Probes direkt bestimmen, ob Nutzer gesunde Pods treffen und ob kaputte Pods automatisch wiederhergestellt werden, ist es grundlegend für den Betrieb zuverlässiger, produktionsreifer Workloads auf Kubernetes, sie richtig zu machen.

Die drei Probes auf einen Blick

Readiness vs. liveness — die zentrale Unterscheidung

Probe-Definitionen

Probe-Mechanismen

Warum es startup-Probes gibt

Warum es wichtig ist

Ähnliche Fragen