Mik azok a liveness, readiness és startup probe-ok, és mikor használod melyiket?

Question

IT Interview Practice · Accepted Answer

A probe-ok lehetővé teszik, hogy a kubelet ellenőrizze egy konténer állapotát, és cselekedjen az eredmény alapján. Három van belőlük: **liveness** (életben van-e, vagy újra kell indítani?), **readiness** (kész-e forgalmat fogadni?) és **startup** (befejezte-e már az indulást?). Mindegyik más kérdésre válaszol.

## A három probe egy pillantásra

```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 — a kulcs megkülönböztetés

```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 definíciók

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

startupProbe:            # időt ad a lassú indulónak, mielőtt a többi beindul
        httpGet: { path: /healthz, port: 8080 }
        failureThreshold: 30   # 30 * 10s = akár 5 perc az induláshoz
        periodSeconds: 10

readinessProbe:          # a forgalom kapuzása
        httpGet: { path: /ready, port: 8080 }
        initialDelaySeconds: 5
        periodSeconds: 10

livenessProbe:           # újraindítás, ha egészségtelen
        httpGet: { path: /healthz, port: 8080 }
        periodSeconds: 10
        failureThreshold: 3
```

## Probe mechanizmusok

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

## Miért léteznek a startup probe-ok

```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     # probe-hibák és újraindítási okok az eseményekben
kubectl get pod app          # a READY oszlop a readinesst, a RESTARTS a livenesst tükrözi
```

## Miért fontos

A health probe-ok adják a Kubernetes öngyógyítását és a biztonságos forgalom-routingot, ezért a három típus és annak megértése, mikor melyiket használd, elengedhetetlen megbízhatósági tudás. A döntő megkülönböztetés — amelyen sok mérnök elbukik — a **readiness** és a **liveness** között van: a readiness a **forgalmat** vezérli (egy bukó Podot kihúznak a Service load balancerből, de tovább fut, ideális, ha bemelegszik vagy egy függősége átmenetileg elérhetetlen), míg a liveness az **életet** vezérli (egy bukó Podot megölnek és újraindítanak, arra az esetre, ha helyreállíthatatlanul beragadt). A kettő összekeverése — liveness probe használata ott, ahol readiness kellett volna — fölösleges újraindítási hurkokat és kimaradásokat okoz, ezért közvetlenül gyakorlati tudás, hogy melyik probe melyik kérdésre válaszol. A **startup** probe egy valódi történelmi fájdalmat old meg: a lassan induló alkalmazások korábban hatalmas `initialDelaySeconds` beállítását kényszerítették ki a livenessnél (ami késleltette a valódi összeomlások észlelését), míg egy startup probe megvédi az indulási ablakot, és a liveness/readiness csak akkor kezd szoros, normál időzítésekkel futni, ha az indulás sikerült. A probe mechanizmusok (`httpGet`, `tcpSocket`, `exec`, `grpc`) és a hangolási paraméterek (`initialDelaySeconds`, `periodSeconds`, `failureThreshold` stb.) megértése lehetővé teszi az egészség-ellenőrzés helyes konfigurálását találgatás helyett. Mivel a probe-ok közvetlenül meghatározzák, hogy a felhasználók egészséges Podokat érnek-e el, és hogy a hibás Podok automatikusan helyreállnak-e, a helyes beállításuk alapvető a megbízható, production-szintű workloadok futtatásához Kubernetesen.

A három probe egy pillantásra

Readiness vs liveness — a kulcs megkülönböztetés

Probe definíciók

Probe mechanizmusok

Miért léteznek a startup probe-ok

Miért fontos

Kapcsolódó kérdések