Hvad er liveness-, readiness- og startup-probes, og hvornår bruger man hver af dem?

Question

IT Interview Practice · Accepted Answer

Probes lader kubelet tjekke en containers helbred og handle på resultatet. Der er tre: **liveness** (er den i live, eller skal den genstartes?), **readiness** (er den klar til at modtage trafik?) og **startup** (er den færdig med at boote?). Hver besvarer et forskelligt spørgsmål.

## De tre probes i et overblik

```text
LIVENESS   → "Hænger/deadlocker appen?"        FEJL → kubelet GENSTARTER containeren
READINESS  → "Kan den betjene trafik lige nu?" FEJL → Pod fjernes fra Service-endpoints
                                                       (IKKE genstartet)
STARTUP    → "Er den langsomme boot færdig?"   kører FØRST; mens den kører, holdes
                                                liveness & readiness tilbage
```

## Readiness vs liveness — den centrale skelnen

```text
Readiness styrer TRAFIK:
  → en Pod, der fejler readiness, trækkes UD af Service-load-balanceren,
    men fortsætter med at køre (fx varmer den en cache op, eller en dependency er nede)
Liveness styrer LIV:
  → en Pod, der fejler liveness, DRÆBES og genstartes (den er ødelagt uden mulighed for at komme sig)
At bruge liveness, hvor du mente readiness, forårsager unødvendige genstart-loops.
```

## Probe-definitioner

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

startupProbe:            # giver en langsom starter tid, før de andre træder i kraft
        httpGet: { path: /healthz, port: 8080 }
        failureThreshold: 30   # 30 * 10s = op til 5 min at starte
        periodSeconds: 10

readinessProbe:          # afgræns trafik
        httpGet: { path: /ready, port: 8080 }
        initialDelaySeconds: 5
        periodSeconds: 10

livenessProbe:           # genstart hvis usund
        httpGet: { path: /healthz, port: 8080 }
        periodSeconds: 10
        failureThreshold: 3
```

## Probe-mekanismer

```text
httpGet    → GET en sti; 2xx/3xx = bestået      (mest almindelig for web-apps)
tcpSocket  → kan vi åbne en TCP-forbindelse?     (til ikke-HTTP-services)
exec       → kør en kommando; exit 0 = bestået   (brugerdefinerede tjek)
grpc       → indbygget gRPC health check
Vigtige knapper: initialDelaySeconds, periodSeconds, timeoutSeconds,
           failureThreshold, successThreshold.
```

## Hvorfor startup-probes findes

```text
Langsomt startende apps (JVM-warmup, store migreringer) tvang dig før til at sætte en
enorm initialDelaySeconds på liveness — hvilket så gjorde rigtige crashes langsomme at opdage.
startupProbe løser dette: den beskytter den langsomme boot, og FØRST når den består,
begynder liveness/readiness med deres normale (stramme) timings.
```

```bash
kubectl describe pod app     # se probe-fejl & genstart-årsager i events
kubectl get pod app          # READY-kolonnen afspejler readiness; RESTARTS afspejler liveness
```

## Hvorfor det betyder noget

Health probes er måden, Kubernetes leverer self-healing og sikker trafik-routing på, så det er essentiel pålidelighedsviden at forstå de tre typer, og hvornår man bruger hver. Den afgørende skelnen — en, der spænder ben for mange ingeniører — er mellem **readiness** og **liveness**: readiness styrer **trafik** (en fejlende Pod trækkes ud af Service-load-balanceren, men fortsætter med at køre, ideelt når den varmer op, eller en dependency er midlertidigt nede), mens liveness styrer **liv** (en fejlende Pod dræbes og genstartes, til når den er deadlocked uden mulighed for at komme sig). At forveksle de to — at bruge en liveness-probe, hvor readiness var meningen — forårsager unødvendige genstart-loops og nedbrud, så at vide, hvilket spørgsmål hver probe besvarer, er direkte praktisk. **Startup**-proben løser en reel historisk smerte: langsomt bootende apps tvang engang til en enorm `initialDelaySeconds` på liveness (hvilket forsinkede opdagelsen af ægte crashes), hvorimod en startup-probe beskytter boot-vinduet og lader liveness/readiness køre med stramme, normale timings, først når startup lykkes. At forstå probe-mekanismerne (`httpGet`, `tcpSocket`, `exec`, `grpc`) og tuning-knapperne (`initialDelaySeconds`, `periodSeconds`, `failureThreshold`, osv.) lader dig konfigurere health checking korrekt frem for på gætteri. Da probes direkte afgør, om brugere rammer sunde Pods, og om ødelagte Pods kommer sig automatisk, er det at få dem rigtige fundamentalt for at køre pålidelige workloads i produktionskvalitet på Kubernetes.

De tre probes i et overblik

Readiness vs liveness — den centrale skelnen

Probe-definitioner

Probe-mekanismer

Hvorfor startup-probes findes

Hvorfor det betyder noget

Relaterede spørgsmål