Wat zijn liveness-, readiness- en startup-probes, en wanneer gebruik je elk?

Question

IT Interview Practice · Accepted Answer

Probes laten de kubelet de gezondheid van een container controleren en op het resultaat handelen. Er zijn er drie: **liveness** (leeft hij, of moet hij herstart worden?), **readiness** (is hij klaar om verkeer te ontvangen?), en **startup** (is hij al klaar met opstarten?). Elk beantwoordt een andere vraag.

## De drie probes in één oogopslag

```text
LIVENESS   → "Zit de app vast/in deadlock?"    FAAL → kubelet HERSTART de container
READINESS  → "Kan hij nu verkeer bedienen?"     FAAL → Pod verwijderd uit Service-endpoints
                                                       (NIET herstart)
STARTUP    → "Is de trage boot al klaar?"       draait EERST; terwijl hij draait, worden
                                                liveness & readiness uitgesteld
```

## Readiness vs liveness — het cruciale onderscheid

```text
Readiness stuurt VERKEER:
  → een Pod die readiness faalt wordt UIT de Service-load-balancer gehaald,
    maar blijft draaien (bijv. het warmt een cache op of een dependency is down)
Liveness stuurt LEVEN:
  → een Pod die liveness faalt wordt GEDOOD en herstart (onherstelbaar kapot)
Liveness gebruiken waar je readiness bedoelde, veroorzaakt onnodige restart loops.
```

## Probe-definities

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

startupProbe:            # geeft een trage starter tijd voordat de rest inschiet
        httpGet: { path: /healthz, port: 8080 }
        failureThreshold: 30   # 30 * 10s = tot 5 min om te starten
        periodSeconds: 10

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

livenessProbe:           # herstart indien ongezond
        httpGet: { path: /healthz, port: 8080 }
        periodSeconds: 10
        failureThreshold: 3
```

## Probe-mechanismen

```text
httpGet    → GET een pad; 2xx/3xx = geslaagd     (meest gebruikelijk voor web apps)
tcpSocket  → kunnen we een TCP-connectie openen?  (voor niet-HTTP-services)
exec       → voer een commando uit; exit 0 = geslaagd  (custom checks)
grpc       → native gRPC health check
Belangrijke knoppen: initialDelaySeconds, periodSeconds, timeoutSeconds,
                     failureThreshold, successThreshold.
```

## Waarom startup-probes bestaan

```text
Traag startende apps (JVM warmup, grote migraties) dwongen je vroeger een enorme
initialDelaySeconds op liveness te zetten — waardoor echte crashes traag te detecteren werden.
De startupProbe lost dit op: hij beschermt de trage boot, en PAS nadat hij slaagt
beginnen liveness/readiness met hun normale (strakke) timings.
```

```bash
kubectl describe pod app     # zie probe-fouten & restart-redenen in events
kubectl get pod app          # kolom READY weerspiegelt readiness; RESTARTS weerspiegelt liveness
```

## Waarom het belangrijk is

Health probes zijn hoe Kubernetes self-healing en veilige verkeersroutering levert, dus de drie types begrijpen en wanneer je elk gebruikt, is essentiële betrouwbaarheidskennis. Het cruciale onderscheid — waar veel engineers over struikelen — is tussen **readiness** en **liveness**: readiness stuurt **verkeer** (een falende Pod wordt uit de Service-load-balancer gehaald maar blijft draaien, ideaal wanneer hij opwarmt of een dependency tijdelijk down is), terwijl liveness **leven** stuurt (een falende Pod wordt gedood en herstart, voor wanneer hij onherstelbaar in deadlock zit). De twee verwarren — een liveness probe gebruiken waar readiness was bedoeld — veroorzaakt onnodige restart loops en storingen, dus weten welke vraag elke probe beantwoordt is direct praktisch. De **startup** probe lost een echte historische pijn op: traag bootende apps dwongen ooit enorme `initialDelaySeconds` op liveness af (wat detectie van echte crashes vertraagde), terwijl een startup probe het bootvenster beschermt en liveness/readiness pas met strakke, normale timings laat draaien zodra het opstarten slaagt. De probe-mechanismen (`httpGet`, `tcpSocket`, `exec`, `grpc`) en de afstelknoppen (`initialDelaySeconds`, `periodSeconds`, `failureThreshold`, enz.) begrijpen, laat je health checking correct configureren in plaats van op gevoel. Omdat probes direct bepalen of gebruikers gezonde Pods raken en of kapotte Pods automatisch herstellen, is ze goed instellen fundamenteel om betrouwbare, production-grade workloads op Kubernetes te draaien.

De drie probes in één oogopslag

Readiness vs liveness — het cruciale onderscheid

Probe-definities

Probe-mechanismen

Waarom startup-probes bestaan

Waarom het belangrijk is

Gerelateerde vragen