Što su liveness, readiness i startup probeovi te kada koristiti svaki?

Question

IT Interview Practice · Accepted Answer

Probeovi omogućuju kubeletu da provjeri zdravlje kontejnera i djeluje prema rezultatu. Postoje tri: **liveness** (je li živ ili ga treba restartati?), **readiness** (je li spreman primati promet?) i **startup** (je li završio pokretanje?). Svaki odgovara na drugo pitanje.

## Tri probea na prvi pogled

```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 naspram livenessa — ključna razlika

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

## Definicije probeova

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

startupProbe:            # daje sporom pokretaču vremena prije nego ostali krenu
        httpGet: { path: /healthz, port: 8080 }
        failureThreshold: 30   # 30 * 10s = do 5 min za pokretanje
        periodSeconds: 10

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

livenessProbe:           # restart ako je nezdrav
        httpGet: { path: /healthz, port: 8080 }
        periodSeconds: 10
        failureThreshold: 3
```

## Mehanizmi probea

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

## Zašto startup probeovi postoje

```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     # vidi padove probea i razloge restarta u događajima
kubectl get pod app          # stupac READY odražava readiness; RESTARTS odražava liveness
```

## Zašto je to važno

Health probeovi su način na koji Kubernetes pruža samoizlječenje i sigurno usmjeravanje prometa, pa je razumijevanje triju tipova i kada koji koristiti bitno znanje o pouzdanosti. Ključna razlika — ona koja spotiče mnoge inženjere — je između **readinessa** i **livenessa**: readiness regulira **promet** (Pod koji pada izbacuje se iz Service load-balancera, ali nastavlja raditi, idealno kad se zagrijava ili je ovisnost privremeno nedostupna), dok liveness regulira **život** (Pod koji pada ubija se i restarta, za kad je zaglavljen bez mogućnosti oporavka). Zamjena tih dvaju — korištenje liveness probea gdje je mišljen readiness — uzrokuje nepotrebne petlje restarta i ispade, pa je znati na koje pitanje svaki probe odgovara izravno praktično. **Startup** probe rješava stvarnu povijesnu bol: aplikacije sa sporim pokretanjem nekad su prisiljavale na golem `initialDelaySeconds` na livenessu (što je odgađalo otkrivanje stvarnih padova), dok startup probe štiti prozor pokretanja i pušta liveness/readiness da rade s uskim, normalnim vremenima tek nakon što pokretanje uspije. Razumijevanje mehanizama probea (`httpGet`, `tcpSocket`, `exec`, `grpc`) i podesivih parametara (`initialDelaySeconds`, `periodSeconds`, `failureThreshold` itd.) omogućuje vam ispravno konfiguriranje provjere zdravlja umjesto nagađanja. Budući da probeovi izravno određuju hoće li korisnici doprijeti do zdravih Podova i hoće li se pokvareni Podovi automatski oporaviti, njihovo ispravno postavljanje temeljno je za pokretanje pouzdanih, produkcijskih workloadova na Kubernetesu.

Tri probea na prvi pogled

Readiness naspram livenessa — ključna razlika

Definicije probeova

Mehanizmi probea

Zašto startup probeovi postoje

Zašto je to važno

Povezana pitanja