Kaj so liveness, readiness in startup probes ter kdaj uporabite katero?

Question

IT Interview Practice · Accepted Answer

Probes omogočajo kubeletu, da preveri zdravje vsebnika in ukrepa glede na rezultat. So tri: **liveness** (ali je živ ali ga je treba znova zagnati?), **readiness** (ali je pripravljen sprejemati promet?) in **startup** (ali je zagon že končan?). Vsaka odgovarja na drugačno vprašanje.

## Tri probes na hitro

```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 proti liveness — 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 probes

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

startupProbe:            # počasnemu zaganjalcu da čas, preden vskočijo drugi
        httpGet: { path: /healthz, port: 8080 }
        failureThreshold: 30   # 30 * 10s = do 5 min za zagon
        periodSeconds: 10

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

livenessProbe:           # znova zaženi, če ni zdrav
        httpGet: { path: /healthz, port: 8080 }
        periodSeconds: 10
        failureThreshold: 3
```

## Mehanizmi probes

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

## Zakaj startup probes obstajajo

```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     # poglej napake probes in razloge za restart v dogodkih
kubectl get pod app          # stolpec READY odraža readiness; RESTARTS odraža liveness
```

## Zakaj je to pomembno

Health probes so način, kako Kubernetes zagotavlja samodejno okrevanje in varno usmerjanje prometa, zato je razumevanje treh vrst in tega, kdaj uporabiti katero, bistveno znanje o zanesljivosti. Ključna razlika — ob katero se spotakne veliko inženirjev — je med **readiness** in **liveness**: readiness nadzira **promet** (Pod, ki pade, se izvzame iz load balancerja Service, a še naprej teče, kar je idealno, kadar se ogreva ali je odvisnost začasno nedosegljiva), medtem ko liveness nadzira **življenje** (Pod, ki pade, se ubije in znova zažene, za kadar je zablokiran onkraj okrevanja). Zamenjava obeh — uporaba liveness probe, kjer je bila mišljena readiness — povzroči nepotrebne zanke ponovnega zagona in izpade, zato je vedeti, na katero vprašanje odgovarja vsaka proba, neposredno praktično. **Startup** proba rešuje resnično zgodovinsko bolečino: aplikacije s počasnim zagonom so nekoč silile v ogromen `initialDelaySeconds` na liveness (kar je zavleklo odkrivanje pravih sesutij), medtem ko startup proba varuje zagonsko okno in pusti, da liveness/readiness tečeta s tesnimi, normalnimi časovnicami šele, ko zagon uspe. Razumevanje mehanizmov probes (`httpGet`, `tcpSocket`, `exec`, `grpc`) in gumbov za uravnavanje (`initialDelaySeconds`, `periodSeconds`, `failureThreshold` itd.) vam omogoča, da preverjanje zdravja nastavite pravilno, ne z ugibanjem. Ker probes neposredno določajo, ali uporabniki zadenejo zdrave Pode in ali se pokvarjeni Podi samodejno obnovijo, je pravilna nastavitev temeljna za poganjanje zanesljivih delovnih obremenitev produkcijske ravni na Kubernetesu.

Tri probes na hitro

Readiness proti liveness — ključna razlika

Definicije probes

Mehanizmi probes

Zakaj startup probes obstajajo

Zakaj je to pomembno

Povezana vprašanja