Czym są liveness, readiness i startup probe i kiedy używać każdego z nich?

Question

IT Interview Practice · Accepted Answer

Probe pozwalają kubeletowi sprawdzać zdrowie kontenera i działać na podstawie wyniku. Są trzy: **liveness** (czy żyje, czy powinien zostać zrestartowany?), **readiness** (czy jest gotowy przyjmować ruch?) oraz **startup** (czy zakończył już rozruch?). Każdy odpowiada na inne pytanie.

## Trzy probe w skrócie

```text
LIVENESS   → "Czy aplikacja zawiesiła się/zakleszczyła?"  FAIL → kubelet RESTARTUJE kontener
READINESS  → "Czy może teraz obsługiwać ruch?"  FAIL → Pod usunięty z endpointów Service
                                                       (NIE restartowany)
STARTUP    → "Czy powolny rozruch się zakończył?"  uruchamia się PIERWSZY; gdy działa, liveness
                                                i readiness są wstrzymane
```

## Readiness vs liveness — kluczowe rozróżnienie

```text
Readiness steruje RUCHEM:
  → Pod, który nie przejdzie readiness, jest WYCIĄGANY z load-balancera Service,
    ale działa dalej (np. rozgrzewa cache lub zależność jest niedostępna)
Liveness steruje ŻYCIEM:
  → Pod, który nie przejdzie liveness, jest ZABIJANY i restartowany (zepsuty nie do odzyskania)
Użycie liveness tam, gdzie chodziło o readiness, powoduje niepotrzebne pętle restartów.
```

## Definicje probe

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

startupProbe:            # daje powolnemu starterowi czas, zanim ruszą pozostałe
        httpGet: { path: /healthz, port: 8080 }
        failureThreshold: 30   # 30 * 10s = do 5 min na start
        periodSeconds: 10

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

livenessProbe:           # restartuj, jeśli niezdrowy
        httpGet: { path: /healthz, port: 8080 }
        periodSeconds: 10
        failureThreshold: 3
```

## Mechanizmy probe

```text
httpGet    → GET na ścieżkę; 2xx/3xx = pass       (najczęstsze dla aplikacji web)
tcpSocket  → czy da się otworzyć połączenie TCP?   (dla usług nie-HTTP)
exec       → uruchom polecenie; exit 0 = pass      (własne sprawdzenia)
grpc       → natywny health check gRPC
Kluczowe pokrętła: initialDelaySeconds, periodSeconds, timeoutSeconds,
           failureThreshold, successThreshold.
```

## Dlaczego istnieją startup probe

```text
Wolno startujące aplikacje (rozgrzewka JVM, duże migracje) kiedyś zmuszały do ustawienia
ogromnego initialDelaySeconds na liveness — co potem sprawiało, że prawdziwe awarie były
wykrywane wolno. startupProbe to naprawia: chroni powolny rozruch i DOPIERO po jego przejściu
liveness/readiness zaczynają działać ze swoimi normalnymi (ciasnymi) czasami.
```

```bash
kubectl describe pod app     # zobacz porażki probe i powody restartów w zdarzeniach
kubectl get pod app          # kolumna READY odzwierciedla readiness; RESTARTS odzwierciedla liveness
```

## Dlaczego to ważne

Health probe to sposób, w jaki Kubernetes dostarcza self-healing i bezpieczne kierowanie ruchu, więc zrozumienie trzech typów i tego, kiedy każdego użyć, to niezbędna wiedza o niezawodności. Kluczowe rozróżnienie — takie, które podkłada nogę wielu inżynierom — jest między **readiness** a **liveness**: readiness steruje **ruchem** (wadliwy Pod jest wyciągany z load-balancera Service, ale działa dalej, idealnie, gdy się rozgrzewa lub zależność jest chwilowo niedostępna), podczas gdy liveness steruje **życiem** (wadliwy Pod jest zabijany i restartowany, na wypadek gdy jest zakleszczony nie do odzyskania). Mylenie obu — użycie liveness probe tam, gdzie chodziło o readiness — powoduje niepotrzebne pętle restartów i przestoje, więc wiedza, na jakie pytanie odpowiada każdy probe, jest wprost praktyczna. **Startup** probe rozwiązuje realny historyczny ból: wolno startujące aplikacje kiedyś wymuszały ogromne `initialDelaySeconds` na liveness (co opóźniało wykrywanie prawdziwych awarii), podczas gdy startup probe chroni okno rozruchu i pozwala liveness/readiness działać z ciasnymi, normalnymi czasami dopiero po udanym starcie. Zrozumienie mechanizmów probe (`httpGet`, `tcpSocket`, `exec`, `grpc`) i pokręteł strojenia (`initialDelaySeconds`, `periodSeconds`, `failureThreshold` itd.) pozwala konfigurować sprawdzanie zdrowia poprawnie, a nie na wyczucie. Ponieważ probe wprost decydują, czy użytkownicy trafiają na zdrowe Pody i czy zepsute Pody odzyskują się automatycznie, ich poprawne ustawienie jest fundamentalne dla uruchamiania niezawodnych, produkcyjnych workloadów na Kubernetes.

Trzy probe w skrócie

Readiness vs liveness — kluczowe rozróżnienie

Definicje probe

Mechanizmy probe

Dlaczego istnieją startup probe

Dlaczego to ważne

Powiązane pytania