რა არის liveness, readiness და startup probe-ები და როდის იყენებთ თითოეულს?

Question

IT Interview Practice · Accepted Answer

Probe-ები kubelet-ს აძლევენ საშუალებას შეამოწმოს კონტეინერის ჯანმრთელობა და შედეგზე იმოქმედოს. სამია: **liveness** (ცოცხალია თუ უნდა გადაიტვირთოს?), **readiness** (მზადაა ტრაფიკის მისაღებად?) და **startup** (ჩატვირთვა უკვე დაასრულა?). თითოეული სხვადასხვა კითხვას პასუხობს.

## სამი probe ერთი ხედვით

```text
LIVENESS   → "Is the app stuck/deadlocked?"   FAIL → kubelet RESTARTS the container
READINESS  → "Can it serve traffic right now?" FAIL → Pod removed from Service endpoints
                                                       (NOT restarted)
STARTUP    → "Has the slow boot finished?"     runs FIRST; while it runs, liveness &
                                                readiness are held off
```

## Readiness vs liveness — მთავარი განსხვავება

```text
Readiness controls TRAFFIC:
  → a Pod that fails readiness is pulled OUT of the Service load-balancer,
    but keeps running (e.g. it's warming a cache or a dependency is down)
Liveness controls LIFE:
  → a Pod that fails liveness is KILLED and restarted (it's broken beyond recovery)
Using liveness where you meant readiness causes needless restart loops.
```

## Probe-ების განსაზღვრებები

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

startupProbe:            # ნელა ჩამტვირთავს დრო აძლევს სხვების ამოქმედებამდე
        httpGet: { path: /healthz, port: 8080 }
        failureThreshold: 30   # 30 * 10წმ = გასაშვებად 5 წუთამდე
        periodSeconds: 10

readinessProbe:          # ტრაფიკის კონტროლი
        httpGet: { path: /ready, port: 8080 }
        initialDelaySeconds: 5
        periodSeconds: 10

livenessProbe:           # გადატვირთვა, თუ არაჯანსაღია
        httpGet: { path: /healthz, port: 8080 }
        periodSeconds: 10
        failureThreshold: 3
```

## Probe-ის მექანიზმები

```text
httpGet    → GET a path; 2xx/3xx = pass         (most common for web apps)
tcpSocket  → can we open a TCP connection?       (for non-HTTP services)
exec       → run a command; exit 0 = pass        (custom checks)
grpc       → native gRPC health check
Key knobs: initialDelaySeconds, periodSeconds, timeoutSeconds,
           failureThreshold, successThreshold.
```

## რატომ არსებობს startup probe-ები

```text
Slow-starting apps (JVM warmup, big migrations) used to force you to set a huge
initialDelaySeconds on liveness — which then made real crashes slow to detect.
The startupProbe fixes this: it protects the slow boot, and ONLY after it passes
do liveness/readiness begin with their normal (tight) timings.
```

```bash
kubectl describe pod app     # probe-ის ჩავარდნები და restart-ის მიზეზები მოვლენებში
kubectl get pod app          # READY სვეტი ასახავს readiness-ს; RESTARTS ასახავს liveness-ს
```

## რატომ არის ეს მნიშვნელოვანი

health probe-ები არის ის, თუ როგორ აწვდის Kubernetes თვით-აღდგენასა და უსაფრთხო ტრაფიკის მარშრუტიზაციას, ამიტომ სამი ტიპისა და თითოეულის გამოყენების დროის გაგება არსებითი საიმედოობის ცოდნაა. გადამწყვეტი განსხვავება — რომელზეც ბევრი ინჟინერი ცდება — **readiness**-სა და **liveness**-ს შორისაა: readiness აკონტროლებს **ტრაფიკს** (ჩავარდნილი Pod Service-ის load-balancer-იდან იშლება, მაგრამ მუშაობას აგრძელებს, იდეალურია, როცა ის თბება ან დამოკიდებულება დროებით გამორთულია), ხოლო liveness აკონტროლებს **სიცოცხლეს** (ჩავარდნილი Pod იკვლება და გადაიტვირთება, როცა ის აღდგენის მიღმაა deadlock-ში). ორის აღრევა — liveness probe-ის გამოყენება იქ, სადაც readiness იგულისხმებოდა — იწვევს უსარგებლო restart მარყუჟებსა და გათიშვებს, ამიტომ იმის ცოდნა, თუ რომელ კითხვას პასუხობს თითოეული probe, პირდაპირ პრაქტიკულია. **startup** probe აგვარებს რეალურ ისტორიულ ტკივილს: ნელა ჩამტვირთავი აპლიკაციები ადრე აიძულებდნენ დიდი `initialDelaySeconds`-ის დაყენებას liveness-ზე (რაც ნამდვილი crash-ების აღმოჩენას აჭიანურებდა), ხოლო startup probe იცავს ჩატვირთვის ფანჯარას და liveness/readiness-ს მჭიდრო, ნორმალურ დროებით მხოლოდ startup-ის წარმატებით დასრულების შემდეგ უშვებს. probe-ის მექანიზმების (`httpGet`, `tcpSocket`, `exec`, `grpc`) და გასამართი პარამეტრების (`initialDelaySeconds`, `periodSeconds`, `failureThreshold` და ა.შ.) გაგება საშუალებას გაძლევთ health შემოწმება სწორად და არა მიხვედრით დააკონფიგურიროთ. რადგან probe-ები პირდაპირ განსაზღვრავენ, მიდიან თუ არა მომხმარებლები ჯანსაღ Pod-ებთან და აღდგება თუ არა გატეხილი Pod-ები ავტომატურად, მათი სწორად დაყენება ფუნდამენტურია Kubernetes-ზე საიმედო, production-დონის workload-ების გასაშვებად.

სამი probe ერთი ხედვით

Readiness vs liveness — მთავარი განსხვავება

Probe-ების განსაზღვრებები

Probe-ის მექანიზმები

რატომ არსებობს startup probe-ები

რატომ არის ეს მნიშვნელოვანი

დაკავშირებული კითხვები