Kas yra liveness, readiness ir startup probe'ai ir kada kiekvieną naudoti?

Question

IT Interview Practice · Accepted Answer

Probe'ai leidžia kubelet'ui tikrinti konteinerio būklę ir reaguoti į rezultatą. Yra trys: **liveness** (ar jis gyvas, ar reikėtų perkrauti?), **readiness** (ar jis pasiruošęs priimti srautą?) ir **startup** (ar jis jau baigė kilti?). Kiekvienas atsako į skirtingą klausimą.

## Trys probe'ai iš pirmo žvilgsnio

```text
LIVENESS   → "Ar app įstrigo/užstrigo (deadlock)?"  FAIL → kubelet PERKRAUNA konteinerį
READINESS  → "Ar dabar gali aptarnauti srautą?"     FAIL → Pod'as pašalinamas iš Service endpoint'ų
                                                            (NEperkraunamas)
STARTUP    → "Ar lėtas kilimas jau baigtas?"         vykdomas PIRMAS; kol jis vyksta, liveness ir
                                                     readiness sulaikomi
```

## Readiness vs. liveness — pagrindinis skirtumas

```text
Readiness valdo SRAUTĄ:
  → Pod'as, neišlaikęs readiness, IŠIMAMAS iš Service load-balancer'io,
    bet toliau veikia (pvz., šildo cache arba nulūžusi priklausomybė)
Liveness valdo GYVYBĘ:
  → Pod'as, neišlaikęs liveness, NUŽUDOMAS ir perkraunamas (jis sugedęs be vilties atsigauti)
Liveness naudojimas ten, kur turėjote omenyje readiness, sukelia bereikalingus restart ciklus.
```

## Probe'ų apibrėžimai

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

startupProbe:            # duoda lėtam starteriui laiko, kol įsijungia kiti
        httpGet: { path: /healthz, port: 8080 }
        failureThreshold: 30   # 30 * 10s = iki 5 min startui
        periodSeconds: 10

readinessProbe:          # valdo srautą
        httpGet: { path: /ready, port: 8080 }
        initialDelaySeconds: 5
        periodSeconds: 10

livenessProbe:           # perkrauna, jei nesveikas
        httpGet: { path: /healthz, port: 8080 }
        periodSeconds: 10
        failureThreshold: 3
```

## Probe'ų mechanizmai

```text
httpGet    → GET į kelią; 2xx/3xx = praeina       (dažniausiai web aplikacijoms)
tcpSocket  → ar galime atverti TCP jungtį?         (ne-HTTP service'ams)
exec       → vykdo komandą; exit 0 = praeina       (savi patikrinimai)
grpc       → natyvus gRPC health check
Pagrindinės rankenėlės: initialDelaySeconds, periodSeconds, timeoutSeconds,
           failureThreshold, successThreshold.
```

## Kodėl egzistuoja startup probe'ai

```text
Lėtai kylančios aplikacijos (JVM apšilimas, didelės migracijos) anksčiau vertė nustatyti didžiulį
initialDelaySeconds ant liveness — o tai lėtino tikrų nulūžimų aptikimą.
startupProbe tai išsprendžia: jis saugo lėtą kilimą, ir TIK jam praėjus
liveness/readiness pradeda su savo įprastais (griežtais) laikais.
```

```bash
kubectl describe pod app     # matyti probe klaidas ir restart priežastis įvykiuose
kubectl get pod app          # READY stulpelis atspindi readiness; RESTARTS — liveness
```

## Kodėl tai svarbu

Health probe'ai yra tai, kaip Kubernetes suteikia savaiminį atsistatymą ir saugų srauto maršrutizavimą, tad suprasti tris tipus ir kada kiekvieną naudoti yra esminė patikimumo žinia. Lemiamas skirtumas — ant kurio užkliūva daugelis inžinierių — yra tarp **readiness** ir **liveness**: readiness valdo **srautą** (neišlaikantis Pod'as išimamas iš Service load-balancer'io, bet toliau veikia — idealu, kai jis šildosi arba priklausomybė laikinai nulūžusi), o liveness valdo **gyvybę** (neišlaikantis Pod'as nužudomas ir perkraunamas, kai jis užstrigęs be vilties atsigauti). Šių dviejų sumaišymas — liveness probe naudojimas ten, kur turėta omenyje readiness — sukelia bereikalingus restart ciklus ir nutrūkimus, tad žinoti, į kurį klausimą kiekvienas probe atsako, yra tiesiogiai praktiška. **Startup** probe išsprendžia realų istorinį skausmą: lėtai kylančios aplikacijos anksčiau vertė nustatyti didžiulį `initialDelaySeconds` ant liveness (kas lėtino tikrų nulūžimų aptikimą), o startup probe saugo kilimo langą ir leidžia liveness/readiness veikti griežtais, įprastais laikais tik startui pavykus. Probe'ų mechanizmų (`httpGet`, `tcpSocket`, `exec`, `grpc`) ir derinimo rankenėlių (`initialDelaySeconds`, `periodSeconds`, `failureThreshold` ir t. t.) supratimas leidžia sukonfigūruoti health check teisingai, o ne spėliojant. Kadangi probe'ai tiesiogiai lemia, ar naudotojai pataiko į sveikus Pod'us ir ar sugedę Pod'ai atsistato automatiškai, jų teisingas nustatymas yra pamatinis patikimiems, production lygio workload'ams Kubernetes'e paleisti.

Trys probe'ai iš pirmo žvilgsnio

Readiness vs. liveness — pagrindinis skirtumas

Probe'ų apibrėžimai

Probe'ų mechanizmai

Kodėl egzistuoja startup probe'ai

Kodėl tai svarbu

Susiję klausimai