Ce sunt liveness, readiness și startup probes și când folosești fiecare?

Question

IT Interview Practice · Accepted Answer

Probes permit kubelet-ului să verifice sănătatea unui container și să acționeze pe baza rezultatului. Sunt trei: **liveness** (este viu, sau ar trebui repornit?), **readiness** (este gata să primească trafic?) și **startup** (a terminat de pornit?). Fiecare răspunde la o întrebare diferită.

## Cele trei probes pe scurt

```text
LIVENESS   → "Este app-ul blocat/deadlocked?"   FAIL → kubelet REPORNEȘTE containerul
READINESS  → "Poate servi trafic chiar acum?"   FAIL → Pod scos din endpoint-urile Service-ului
                                                       (NU repornit)
STARTUP    → "S-a terminat pornirea lentă?"      rulează PRIMUL; cât timp rulează, liveness &
                                                readiness sunt amânate
```

## Readiness vs liveness — distincția cheie

```text
Readiness controlează TRAFICUL:
  → un Pod care pică readiness este SCOS din load-balancer-ul Service-ului,
    dar continuă să ruleze (ex. își încălzește un cache sau o dependență e picată)
Liveness controlează VIAȚA:
  → un Pod care pică liveness este UCIS și repornit (e stricat dincolo de recuperare)
Folosirea liveness acolo unde voiai readiness cauzează bucle inutile de restart.
```

## Definirea probes

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

startupProbe:            # dă timp unui starter lent înainte ca ceilalți să intre
        httpGet: { path: /healthz, port: 8080 }
        failureThreshold: 30   # 30 * 10s = până la 5 min pentru pornire
        periodSeconds: 10

readinessProbe:          # controlează traficul
        httpGet: { path: /ready, port: 8080 }
        initialDelaySeconds: 5
        periodSeconds: 10

livenessProbe:           # repornește dacă e nesănătos
        httpGet: { path: /healthz, port: 8080 }
        periodSeconds: 10
        failureThreshold: 3
```

## Mecanismele probes

```text
httpGet    → GET pe un path; 2xx/3xx = pass         (cel mai comun pentru aplicații web)
tcpSocket  → putem deschide o conexiune TCP?         (pentru servicii non-HTTP)
exec       → rulează o comandă; exit 0 = pass        (verificări custom)
grpc       → verificare de sănătate gRPC nativă
Butoane cheie: initialDelaySeconds, periodSeconds, timeoutSeconds,
           failureThreshold, successThreshold.
```

## De ce există startup probes

```text
Aplicațiile care pornesc lent (warmup JVM, migrări mari) te forțau odată să setezi un
initialDelaySeconds uriaș pe liveness — ceea ce făcea ca crash-urile reale să fie detectate lent.
startupProbe rezolvă asta: protejează pornirea lentă, și DOAR după ce trece
încep liveness/readiness cu timing-urile lor normale (strânse).
```

```bash
kubectl describe pod app     # vezi eșecurile de probe & motivele de restart în evenimente
kubectl get pod app          # coloana READY reflectă readiness; RESTARTS reflectă liveness
```

## De ce contează

Health probes sunt modul în care Kubernetes livrează self-healing și rutare sigură a traficului, așa că înțelegerea celor trei tipuri și a momentului potrivit pentru fiecare este cunoaștere esențială de fiabilitate. Distincția crucială — una care încurcă mulți ingineri — este între **readiness** și **liveness**: readiness controlează **traficul** (un Pod care pică este scos din load-balancer-ul Service-ului dar continuă să ruleze, ideal când se încălzește sau o dependență e temporar picată), în timp ce liveness controlează **viața** (un Pod care pică este ucis și repornit, pentru când e blocat dincolo de recuperare). Confundarea celor două — folosirea unei liveness probe unde se voia readiness — cauzează bucle inutile de restart și pene, deci a ști la ce întrebare răspunde fiecare probe este direct practic. Probe-ul **startup** rezolvă o durere istorică reală: aplicațiile care porneau lent forțau odată `initialDelaySeconds` uriaș pe liveness (ceea ce întârzia detectarea crash-urilor reale), în timp ce un startup probe protejează fereastra de pornire și lasă liveness/readiness să ruleze cu timing-uri strânse, normale, doar după ce pornirea reușește. Înțelegerea mecanismelor de probe (`httpGet`, `tcpSocket`, `exec`, `grpc`) și a butoanelor de reglaj (`initialDelaySeconds`, `periodSeconds`, `failureThreshold` etc.) îți permite să configurezi verificarea sănătății corect, nu prin ghicit. Deoarece probes determină direct dacă utilizatorii ajung la Pod-uri sănătoase și dacă Pod-urile stricate se recuperează automat, configurarea lor corectă este fundamentală pentru a rula workload-uri fiabile, de nivel de producție, pe Kubernetes.

Cele trei probes pe scurt

Readiness vs liveness — distincția cheie

Definirea probes

Mecanismele probes

De ce există startup probes

De ce contează

Întrebări conexe