Τι είναι τα liveness, readiness και startup probes, και πότε χρησιμοποιείς το καθένα;

Question

IT Interview Practice · Accepted Answer

Τα probes επιτρέπουν στο kubelet να ελέγχει την υγεία ενός container και να ενεργεί βάσει του αποτελέσματος. Υπάρχουν τρία: **liveness** (είναι ζωντανό, ή πρέπει να επανεκκινήσει;), **readiness** (είναι έτοιμο να λάβει κίνηση;), και **startup** (έχει τελειώσει το boot του;). Καθένα απαντά σε διαφορετική ερώτηση.

## Τα τρία probes με μια ματιά

```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.
```

## Ορισμοί των probes

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

startupProbe:            # δίνει χρόνο σε ένα αργό starter πριν μπουν τα άλλα
        httpGet: { path: /healthz, port: 8080 }
        failureThreshold: 30   # 30 * 10s = έως 5 λεπτά για εκκίνηση
        periodSeconds: 10

readinessProbe:          # έλεγχος της κίνησης
        httpGet: { path: /ready, port: 8080 }
        initialDelaySeconds: 5
        periodSeconds: 10

livenessProbe:           # restart αν δεν είναι υγιές
        httpGet: { path: /healthz, port: 8080 }
        periodSeconds: 10
        failureThreshold: 3
```

## Μηχανισμοί των probes

```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 probes

```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 στα events
kubectl get pod app          # η στήλη READY δείχνει το readiness· το RESTARTS δείχνει το liveness
```

## Γιατί έχει σημασία

Τα health probes είναι ο τρόπος με τον οποίο το Kubernetes παρέχει αυτο-επιδιόρθωση και ασφαλή δρομολόγηση κίνησης, οπότε η κατανόηση των τριών τύπων και του πότε να χρησιμοποιείς τον καθένα είναι απαραίτητη γνώση αξιοπιστίας. Η κρίσιμη διάκριση — μία που μπερδεύει πολλούς μηχανικούς — είναι μεταξύ **readiness** και **liveness**: το readiness ελέγχει την **κίνηση** (ένα Pod που αποτυγχάνει βγαίνει από τον load-balancer του Service αλλά συνεχίζει να τρέχει, ιδανικό όταν κάνει warm up ή μια εξάρτηση είναι προσωρινά εκτός), ενώ το liveness ελέγχει τη **ζωή** (ένα Pod που αποτυγχάνει σκοτώνεται και επανεκκινεί, για όταν έχει κολλήσει πέρα από κάθε ανάκαμψη). Το μπέρδεμα των δύο — η χρήση liveness probe εκεί που εννοούσες readiness — προκαλεί άσκοπους βρόχους restart και outages, οπότε το να ξέρεις σε ποια ερώτηση απαντά το κάθε probe είναι άμεσα πρακτικό. Το **startup** probe λύνει ένα πραγματικό ιστορικό πρόβλημα: οι εφαρμογές που ξεκινούν αργά κάποτε ανάγκαζαν σε τεράστια `initialDelaySeconds` στο liveness (που καθυστερούσε τον εντοπισμό πραγματικών κρας), ενώ ένα startup probe προστατεύει το παράθυρο του boot και αφήνει τα liveness/readiness να τρέξουν με στενά, κανονικά timings μόνο αφού πετύχει το startup. Η κατανόηση των μηχανισμών των probes (`httpGet`, `tcpSocket`, `exec`, `grpc`) και των παραμέτρων ρύθμισης (`initialDelaySeconds`, `periodSeconds`, `failureThreshold`, κ.λπ.) σού επιτρέπει να ρυθμίζεις σωστά τον έλεγχο υγείας αντί για μαντεψιά. Επειδή τα probes καθορίζουν άμεσα αν οι χρήστες φτάνουν σε υγιή Pods και αν τα χαλασμένα Pods ανακάμπτουν αυτόματα, το να τα κάνεις σωστά είναι θεμελιώδες για να τρέχεις αξιόπιστα workloads production-grade στο Kubernetes.

Τα τρία probes με μια ματιά

Readiness vs liveness — η βασική διάκριση

Ορισμοί των probes

Μηχανισμοί των probes

Γιατί υπάρχουν τα startup probes

Γιατί έχει σημασία

Σχετικές ερωτήσεις