Çfarë janë liveness, readiness dhe startup probe-t, dhe kur përdor secilin?

Question

IT Interview Practice · Accepted Answer

Probe-t i lejojnë kubelet-it të kontrollojë shëndetin e një container-i dhe të veprojë mbi rezultatin. Ka tre: **liveness** (a është gjallë, apo duhet të riniset?), **readiness** (a është gati për të marrë trafik?), dhe **startup** (a e ka mbaruar boot-in?). Secili u përgjigjet një pyetjeje të ndryshme.

## Tre probe-t me një shikim

```text
LIVENESS   → "A ka ngecur/deadlock app-i?"      DËSHTIM → kubelet RINIS container-in
READINESS  → "A mund të shërbejë trafik tani?"  DËSHTIM → Pod-i hiqet nga endpoint-et e Service-it
                                                          (NUK riniset)
STARTUP    → "A ka mbaruar boot-i i ngadaltë?"  funksionon I PARI; ndërsa ai punon,
                                                liveness & readiness mbahen mënjanë
```

## Readiness vs liveness — dallimi kyç

```text
Readiness kontrollon TRAFIKUN:
  → një Pod që dështon readiness NXIRRET nga load-balancer-i i Service-it,
    por vazhdon të funksionojë (p.sh. po ngroh një cache ose një dependency është poshtë)
Liveness kontrollon JETËN:
  → një Pod që dështon liveness VRITET dhe riniset (është prishur pa shpresë shërimi)
Përdorimi i liveness aty ku doje readiness shkakton cikle restart-i të kota.
```

## Përkufizimet e probe-ve

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

startupProbe:            # i jep një starter-i të ngadaltë kohë para se të tjerët të hyjnë
        httpGet: { path: /healthz, port: 8080 }
        failureThreshold: 30   # 30 * 10s = deri në 5 min për të nisur
        periodSeconds: 10

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

livenessProbe:           # rinis nëse jo i shëndetshëm
        httpGet: { path: /healthz, port: 8080 }
        periodSeconds: 10
        failureThreshold: 3
```

## Mekanizmat e probe-ve

```text
httpGet    → GET një path; 2xx/3xx = kalon        (më i zakonshmi për web app)
tcpSocket  → a mund të hapim një lidhje TCP?       (për service jo-HTTP)
exec       → ekzekuto një komandë; exit 0 = kalon  (kontrolle të personalizuara)
grpc       → health check native gRPC
Butonat kyç: initialDelaySeconds, periodSeconds, timeoutSeconds,
             failureThreshold, successThreshold.
```

## Pse ekzistojnë startup probe-t

```text
App që nisin ngadalë (JVM warmup, migration të mëdha) të detyronin dikur të vendosje një
initialDelaySeconds të madh te liveness — që pastaj i bënte crash-et reale të ngadalta për t'u zbuluar.
startupProbe e rregullon këtë: mbron boot-in e ngadaltë, dhe VETËM pasi kalon
liveness/readiness nisin me timing-un e tyre normal (të ngushtë).
```

```bash
kubectl describe pod app     # shiko dështimet e probe-ve & arsyet e restart-it në events
kubectl get pod app          # kolona READY pasqyron readiness; RESTARTS pasqyron liveness
```

## Pse ka rëndësi

Health probe-t janë mënyra si Kubernetes ofron vetë-shërim dhe routing të sigurt të trafikut, kështu që të kuptosh tre llojet dhe kur të përdorësh secilin është njohuri thelbësore besueshmërie. Dallimi vendimtar — që pengon shumë inxhinierë — është midis **readiness** dhe **liveness**: readiness kontrollon **trafikun** (një Pod që dështon nxirret nga load-balancer-i i Service-it por vazhdon të funksionojë, ideal kur po ngrohet ose një dependency është përkohësisht poshtë), ndërsa liveness kontrollon **jetën** (një Pod që dështon vritet dhe riniset, për kur ka deadlock pa shpresë shërimi). Ngatërrimi i të dyve — përdorimi i një liveness probe aty ku nënkuptohej readiness — shkakton cikle restart-i të kota dhe ndërprerje, kështu që të dish cilës pyetje i përgjigjet secili probe është drejtpërdrejt praktike. Probe-i **startup** zgjidh një dhimbje reale historike: app që bëjnë boot ngadalë dikur detyronin `initialDelaySeconds` të mëdha te liveness (që vononin zbulimin e crash-eve të vërteta), ndërsa një startup probe mbron dritaren e boot-it dhe i lejon liveness/readiness të funksionojnë me timing të ngushtë, normal vetëm pasi startup-i ka sukses. Të kuptuarit e mekanizmave të probe-ve (`httpGet`, `tcpSocket`, `exec`, `grpc`) dhe butonave të akordimit (`initialDelaySeconds`, `periodSeconds`, `failureThreshold`, etj.) të lejon të konfigurosh health checking-un saktë e jo me hamendje. Meqë probe-t përcaktojnë drejtpërdrejt nëse përdoruesit godasin Pod-e të shëndetshme dhe nëse Pod-et e prishura shërohen automatikisht, bërja e drejtë e tyre është themelore për të drejtuar workload-e të besueshme, të nivelit production në Kubernetes.

Tre probe-t me një shikim

Readiness vs liveness — dallimi kyç

Përkufizimet e probe-ve

Mekanizmat e probe-ve

Pse ekzistojnë startup probe-t

Pse ka rëndësi

Pyetje të ngjashme