Che cosa sono le probe di liveness, readiness e startup, e quando usi ciascuna?

Question

IT Interview Practice · Accepted Answer

Le probe permettono al kubelet di verificare lo stato di salute di un container e di agire in base al risultato. Ce ne sono tre: **liveness** (è vivo, o va riavviato?), **readiness** (è pronto a ricevere traffico?) e **startup** (ha finito di avviarsi?). Ciascuna risponde a una domanda diversa.

## Le tre probe a colpo d'occhio

```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 vs liveness — la distinzione chiave

```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.
```

## Definizioni delle probe

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

startupProbe:            # gives a slow starter time before others kick in
        httpGet: { path: /healthz, port: 8080 }
        failureThreshold: 30   # 30 * 10s = up to 5 min to start
        periodSeconds: 10

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

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

## Meccanismi delle probe

```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.
```

## Perché esistono le startup probe

```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     # see probe failures & restart reasons in events
kubectl get pod app          # READY column reflects readiness; RESTARTS reflects liveness
```

## Perché è importante

Le health probe sono il modo in cui Kubernetes fornisce self-healing e instradamento sicuro del traffico, quindi capire i tre tipi e quando usare ciascuno è una conoscenza essenziale in materia di affidabilità. La distinzione cruciale — quella che fa inciampare molti ingegneri — è tra **readiness** e **liveness**: la readiness controlla il **traffico** (un Pod che fallisce viene tolto dal load-balancer del Service ma continua a girare, ideale quando si sta scaldando o una dipendenza è temporaneamente giù), mentre la liveness controlla la **vita** (un Pod che fallisce viene ucciso e riavviato, per quando è in deadlock oltre ogni recupero). Confondere le due — usare una liveness probe dove si intendeva la readiness — causa inutili loop di riavvio e disservizi, quindi sapere a quale domanda risponde ciascuna probe è di diretta utilità pratica. La probe di **startup** risolve un problema storico reale: le app ad avvio lento un tempo costringevano a impostare enormi `initialDelaySeconds` sulla liveness (ritardando così il rilevamento dei veri crash), mentre una startup probe protegge la finestra di avvio e lascia che liveness/readiness girino con tempistiche strette e normali solo una volta riuscito lo startup. Capire i meccanismi delle probe (`httpGet`, `tcpSocket`, `exec`, `grpc`) e le manopole di tuning (`initialDelaySeconds`, `periodSeconds`, `failureThreshold`, ecc.) ti permette di configurare correttamente il controllo di salute anziché a caso. Poiché le probe determinano direttamente se gli utenti raggiungono Pod sani e se i Pod guasti si recuperano automaticamente, configurarle bene è fondamentale per far girare workload affidabili e di livello produzione su Kubernetes.

Le tre probe a colpo d'occhio

Readiness vs liveness — la distinzione chiave

Definizioni delle probe

Meccanismi delle probe

Perché esistono le startup probe

Perché è importante

Domande correlate