Hva er liveness-, readiness- og startup-probes, og når bruker du hver av dem?

Question

IT Interview Practice · Accepted Answer

Probes lar kubelet sjekke helsen til en container og handle på resultatet. Det finnes tre: **liveness** (lever den, eller bør den restartes?), **readiness** (er den klar til å motta trafikk?), og **startup** (har den fullført oppstart ennå?). Hver svarer på et forskjellig spørsmål.

## De tre probes i et øyekast

```text
LIVENESS   → "Er appen fastlåst/deadlocked?"    FAIL → kubelet RESTARTER containeren
READINESS  → "Kan den betjene trafikk nå?"      FAIL → Pod fjernet fra Service-endpoints
                                                       (IKKE restartet)
STARTUP    → "Er den trege oppstarten ferdig?"  kjører FØRST; mens den kjører, holdes
                                                liveness og readiness tilbake
```

## Readiness vs liveness — det viktige skillet

```text
Readiness styrer TRAFIKK:
  → en Pod som feiler readiness trekkes UT av Service-load-balanceren,
    men fortsetter å kjøre (f.eks. den varmer en cache eller en avhengighet er nede)
Liveness styrer LIV:
  → en Pod som feiler liveness DREPES og restartes (den er ødelagt uten redning)
Å bruke liveness der du mente readiness gir unødvendige restart-loops.
```

## Probe-definisjoner

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

startupProbe:            # gir en treg starter tid før de andre trår til
        httpGet: { path: /healthz, port: 8080 }
        failureThreshold: 30   # 30 * 10s = opptil 5 min for å starte
        periodSeconds: 10

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

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

## Probe-mekanismer

```text
httpGet    → GET en path; 2xx/3xx = bestått      (vanligst for web-apper)
tcpSocket  → kan vi åpne en TCP-tilkobling?       (for ikke-HTTP-tjenester)
exec       → kjør en kommando; exit 0 = bestått   (egendefinerte sjekker)
grpc       → innebygd gRPC health check
Viktige innstillinger: initialDelaySeconds, periodSeconds, timeoutSeconds,
           failureThreshold, successThreshold.
```

## Hvorfor startup-probes finnes

```text
Treg-startende apper (JVM-oppvarming, store migrasjoner) tvang deg før til å sette en
enorm initialDelaySeconds på liveness — som så gjorde ekte krasj trege å oppdage.
startupProbe fikser dette: den beskytter den trege oppstarten, og BARE etter at den
består begynner liveness/readiness med sine normale (stramme) tidsintervaller.
```

```bash
kubectl describe pod app     # se probe-feil og restart-årsaker i events
kubectl get pod app          # READY-kolonnen reflekterer readiness; RESTARTS reflekterer liveness
```

## Hvorfor det er viktig

Health probes er hvordan Kubernetes leverer self-healing og trygg trafikkruting, så å forstå de tre typene og når man bruker hver av dem er essensiell pålitelighetskunnskap. Det avgjørende skillet — et som feller mange ingeniører — er mellom **readiness** og **liveness**: readiness styrer **trafikk** (en feilende Pod trekkes ut av Service-load-balanceren, men fortsetter å kjøre, ideelt når den varmer opp eller en avhengighet er midlertidig nede), mens liveness styrer **liv** (en feilende Pod drepes og restartes, for når den er deadlocked uten redning). Å blande de to — å bruke en liveness probe der readiness var ment — gir unødvendige restart-loops og nedetid, så å vite hvilket spørsmål hver probe svarer på er direkte praktisk. **Startup**-proben løser en reell historisk smerte: treg-startende apper tvang før frem en enorm `initialDelaySeconds` på liveness (som forsinket oppdagelsen av ekte krasj), mens en startup probe beskytter oppstartsvinduet og lar liveness/readiness kjøre med stramme, normale tidsintervaller først når oppstart lykkes. Å forstå probe-mekanismene (`httpGet`, `tcpSocket`, `exec`, `grpc`) og innstillingsrattene (`initialDelaySeconds`, `periodSeconds`, `failureThreshold`, osv.) lar deg konfigurere health checking korrekt i stedet for ved gjetting. Siden probes direkte avgjør om brukere treffer friske Pods og om ødelagte Pods gjenoppretter automatisk, er det å få dem riktig grunnleggende for å kjøre pålitelige workloads i produksjonsklasse på Kubernetes.

De tre probes i et øyekast

Readiness vs liveness — det viktige skillet

Probe-definisjoner

Probe-mekanismer

Hvorfor startup-probes finnes

Hvorfor det er viktig

Relaterte spørsmål