Vad är liveness-, readiness- och startup-probes, och när använder du var och en?

Question

IT Interview Practice · Accepted Answer

Probes låter kubelet kontrollera en containers hälsa och agera på resultatet. Det finns tre: **liveness** (lever den, eller bör den startas om?), **readiness** (är den redo att ta emot trafik?) och **startup** (har den startat klart än?). Var och en besvarar en olika fråga.

## De tre probes i korthet

```text
LIVENESS   → "Is the app stuck/deadlocked?"   FAIL → kubelet RESTARTS the container
READINESS  → "Can it serve traffic right now?" FAIL → Pod removed from Service endpoints
                                                       (NOT restarted)
STARTUP    → "Has the slow boot finished?"     runs FIRST; while it runs, liveness &
                                                readiness are held off
```

## Readiness kontra liveness — den centrala distinktionen

```text
Readiness controls TRAFFIC:
  → a Pod that fails readiness is pulled OUT of the Service load-balancer,
    but keeps running (e.g. it's warming a cache or a dependency is down)
Liveness controls LIFE:
  → a Pod that fails liveness is KILLED and restarted (it's broken beyond recovery)
Using liveness where you meant readiness causes needless restart loops.
```

## Probe-definitioner

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

startupProbe:            # ger en långsam startare tid innan de andra slår till
        httpGet: { path: /healthz, port: 8080 }
        failureThreshold: 30   # 30 * 10s = upp till 5 min att starta
        periodSeconds: 10

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

livenessProbe:           # starta om om ohälsosam
        httpGet: { path: /healthz, port: 8080 }
        periodSeconds: 10
        failureThreshold: 3
```

## Probe-mekanismer

```text
httpGet    → GET a path; 2xx/3xx = pass         (most common for web apps)
tcpSocket  → can we open a TCP connection?       (for non-HTTP services)
exec       → run a command; exit 0 = pass        (custom checks)
grpc       → native gRPC health check
Key knobs: initialDelaySeconds, periodSeconds, timeoutSeconds,
           failureThreshold, successThreshold.
```

## Varför startup-probes finns

```text
Slow-starting apps (JVM warmup, big migrations) used to force you to set a huge
initialDelaySeconds on liveness — which then made real crashes slow to detect.
The startupProbe fixes this: it protects the slow boot, and ONLY after it passes
do liveness/readiness begin with their normal (tight) timings.
```

```bash
kubectl describe pod app     # se probe-fel & orsaker till omstart i events
kubectl get pod app          # READY-kolumnen speglar readiness; RESTARTS speglar liveness
```

## Varför det är viktigt

Health probes är hur Kubernetes levererar self-healing och säker trafik-routing, så att förstå de tre typerna och när man använder var och en är väsentlig tillförlitlighetskunskap. Den avgörande distinktionen — en som fäller många ingenjörer — är mellan **readiness** och **liveness**: readiness styr **trafik** (en fallerande Pod plockas ut ur Service:ens load balancer men fortsätter köra, idealiskt när den värmer upp eller ett beroende tillfälligt är nere), medan liveness styr **liv** (en fallerande Pod dödas och startas om, för när den är låst bortom räddning). Att förväxla de två — att använda en liveness-probe där readiness avsågs — orsakar onödiga omstartsloopar och driftavbrott, så att veta vilken fråga varje probe besvarar är direkt praktiskt. **Startup**-proben löser en verklig historisk smärta: långsamt startande appar tvingade förr fram enorma `initialDelaySeconds` på liveness (vilket fördröjde upptäckten av verkliga krascher), medan en startup-probe skyddar startfönstret och låter liveness/readiness köra med snäva, normala tider först när starten lyckas. Att förstå probe-mekanismerna (`httpGet`, `tcpSocket`, `exec`, `grpc`) och justerrattarna (`initialDelaySeconds`, `periodSeconds`, `failureThreshold`, m.fl.) låter dig konfigurera hälsokontroll korrekt snarare än på gissning. Eftersom probes direkt avgör om användare når friska Pods och om trasiga Pods återhämtar sig automatiskt är det grundläggande att få dem rätt för att köra tillförlitliga, produktionsklara workloads på Kubernetes.

De tre probes i korthet

Readiness kontra liveness — den centrala distinktionen

Probe-definitioner

Probe-mekanismer

Varför startup-probes finns

Varför det är viktigt

Relaterade frågor