Mitä ovat liveness-, readiness- ja startup-probet, ja milloin kutakin käytetään?

Question

IT Interview Practice · Accepted Answer

Probet antavat kubeletin tarkistaa kontin terveyden ja toimia tuloksen perusteella. Niitä on kolme: **liveness** (onko se elossa, vai pitäisikö se käynnistää uudelleen?), **readiness** (onko se valmis vastaanottamaan liikennettä?) ja **startup** (onko se saanut käynnistyksensä valmiiksi?). Kukin vastaa eri kysymykseen.

## Kolme probea yhdellä silmäyksellä

```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 — keskeinen erottelu

```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-määrittelyt

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

startupProbe:            # antaa hitaalle käynnistyjälle aikaa ennen kuin muut alkavat
        httpGet: { path: /healthz, port: 8080 }
        failureThreshold: 30   # 30 * 10s = jopa 5 min käynnistyä
        periodSeconds: 10

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

livenessProbe:           # käynnistä uudelleen jos epäterve
        httpGet: { path: /healthz, port: 8080 }
        periodSeconds: 10
        failureThreshold: 3
```

## Probe-mekanismit

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

## Miksi startup-probet ovat olemassa

```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     # näe probe-epäonnistumiset & uudelleenkäynnistyssyyt tapahtumissa
kubectl get pod app          # READY-sarake heijastaa readinessiä; RESTARTS heijastaa livenessiä
```

## Miksi se on tärkeää

Health-probet ovat se tapa, jolla Kubernetes tuottaa itsekorjauksen ja turvallisen liikenteen reitityksen, joten kolmen tyypin ymmärtäminen ja se milloin kutakin käytetään on olennaista luotettavuustietoa. Ratkaiseva erottelu — sellainen joka kompastuttaa monia insinöörejä — on **readinessin** ja **livenessin** välillä: readiness ohjaa **liikennettä** (epäonnistuva Pod vedetään ulos Servicen kuormantasaajasta mutta pysyy käynnissä, ihanteellista kun se lämmittelee tai riippuvuus on tilapäisesti alhaalla), kun taas liveness ohjaa **elämää** (epäonnistuva Pod tapetaan ja käynnistetään uudelleen, tilanteisiin joissa se on lukkiutunut toipumisen ohi). Näiden kahden sekoittaminen — liveness-proben käyttö siellä missä tarkoitettiin readinessiä — aiheuttaa turhia uudelleenkäynnistyssilmukoita ja katkoja, joten sen tietäminen mihin kysymykseen kukin probe vastaa on suoraan käytännöllistä. **Startup**-probe ratkaisee todellisen historiallisen kivun: hitaasti käynnistyvät sovellukset pakottivat ennen valtavat `initialDelaySeconds`-arvot livenessiin (mikä viivytti aitojen kaatumisten havaitsemista), kun taas startup-probe suojaa käynnistysikkunan ja antaa livenessin/readinessin ajaa tiukoilla, normaaleilla ajoituksilla vasta kun käynnistys onnistuu. Probe-mekanismien (`httpGet`, `tcpSocket`, `exec`, `grpc`) ja säätönuppien (`initialDelaySeconds`, `periodSeconds`, `failureThreshold` jne.) ymmärtäminen antaa sinun konfiguroida terveystarkistuksen oikein arvailun sijaan. Koska probet määräävät suoraan sen, osuvatko käyttäjät terveisiin Podeihin ja toipuvatko rikkinäiset Podit automaattisesti, niiden oikein saaminen on perustavaa luotettavien, tuotantotason työkuormien ajamiselle Kubernetesissa.

Kolme probea yhdellä silmäyksellä

Readiness vs liveness — keskeinen erottelu

Probe-määrittelyt

Probe-mekanismit

Miksi startup-probet ovat olemassa

Miksi se on tärkeää

Aiheeseen liittyvät kysymykset