Co jsou liveness, readiness a startup probe a kdy které použít?

Question

IT Interview Practice · Accepted Answer

Probe umožňují kubeletu kontrolovat zdraví kontejneru a podle výsledku jednat. Jsou tři: **liveness** (žije, nebo se má restartovat?), **readiness** (je připraven přijímat provoz?) a **startup** (dokončil už start?). Každá odpovídá na jinou otázku.

## Tři probe ve zkratce

```text
LIVENESS   → "Je aplikace zaseklá/v deadlocku?"  FAIL → kubelet RESTARTUJE kontejner
READINESS  → "Může teď obsluhovat provoz?"       FAIL → Pod odebrán z endpointů Service
                                                       (NErestartuje se)
STARTUP    → "Dokončil pomalý start?"            běží PRVNÍ; dokud běží, liveness a
                                                readiness jsou pozastaveny
```

## Readiness vs liveness — klíčový rozdíl

```text
Readiness řídí PROVOZ:
  → Pod, který neprojde readiness, je VYŘAZEN z load-balanceru Service,
    ale běží dál (např. zahřívá cache nebo je závislost mimo provoz)
Liveness řídí ŽIVOT:
  → Pod, který neprojde liveness, je ZABIT a restartován (je rozbitý bez naděje na obnovu)
Použití liveness tam, kde jste mysleli readiness, způsobuje zbytečné smyčky restartů.
```

## Definice probe

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

startupProbe:            # dá pomalému startu čas, než se zapojí ostatní
        httpGet: { path: /healthz, port: 8080 }
        failureThreshold: 30   # 30 * 10 s = až 5 min na start
        periodSeconds: 10

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

livenessProbe:           # restart při nezdraví
        httpGet: { path: /healthz, port: 8080 }
        periodSeconds: 10
        failureThreshold: 3
```

## Mechanismy probe

```text
httpGet    → GET na cestu; 2xx/3xx = projde     (nejběžnější pro webové aplikace)
tcpSocket  → lze otevřít TCP spojení?            (pro ne-HTTP služby)
exec       → spustí příkaz; exit 0 = projde      (vlastní kontroly)
grpc       → nativní gRPC health check
Klíčové parametry: initialDelaySeconds, periodSeconds, timeoutSeconds,
           failureThreshold, successThreshold.
```

## Proč startup probe existují

```text
Pomalu startující aplikace (zahřátí JVM, velké migrace) vás dřív nutily nastavit obrovský
initialDelaySeconds na liveness — což pak zpomalilo detekci skutečných pádů.
startupProbe to řeší: chrání pomalý start a AŽ po jejím úspěchu
začnou liveness/readiness s normálním (těsným) časováním.
```

```bash
kubectl describe pod app     # zobrazí selhání probe a důvody restartů v událostech
kubectl get pod app          # sloupec READY odráží readiness; RESTARTS odráží liveness
```

## Proč je to důležité

Health probe jsou způsob, jak Kubernetes zajišťuje self-healing a bezpečné směrování provozu, takže pochopení tří typů a kdy který použít je nezbytná znalost pro spolehlivost. Zásadní rozdíl — o který mnoho inženýrů zakopne — je mezi **readiness** a **liveness**: readiness řídí **provoz** (selhávající Pod je vyřazen z load-balanceru Service, ale běží dál, ideální když se zahřívá nebo je závislost dočasně mimo provoz), zatímco liveness řídí **život** (selhávající Pod je zabit a restartován, pro případ, kdy je v deadlocku bez naděje na obnovu). Záměna obou — použití liveness probe tam, kde byla myšlena readiness — způsobuje zbytečné smyčky restartů a výpadky, takže vědět, na kterou otázku každá probe odpovídá, je přímo praktické. **Startup** probe řeší skutečnou historickou bolest: pomalu startující aplikace kdysi nutily nastavit obrovský `initialDelaySeconds` na liveness (což zdrželo detekci skutečných pádů), zatímco startup probe chrání okno startu a nechá liveness/readiness běžet s těsným, normálním časováním až po úspěšném startu. Pochopení mechanismů probe (`httpGet`, `tcpSocket`, `exec`, `grpc`) a ladicích parametrů (`initialDelaySeconds`, `periodSeconds`, `failureThreshold` atd.) vám umožní nastavit health checking správně, ne odhadem. Protože probe přímo určují, zda uživatelé dopadnou na zdravé Pody a zda se rozbité Pody automaticky zotaví, jejich správné nastavení je základem pro provoz spolehlivých, produkčních workloadů na Kubernetes.

Tři probe ve zkratce

Readiness vs liveness — klíčový rozdíl

Definice probe

Mechanismy probe

Proč startup probe existují

Proč je to důležité

Související otázky