Liveness, readiness, અને startup probes શું છે, અને દરેક ક્યારે વાપરવો?

Question

IT Interview Practice · Accepted Answer

Probes kubelet ને એક container ની તંદુરસ્તી તપાસવા અને પરિણામ પર કાર્ય કરવા દે છે. ત્રણ છે: **liveness** (તે જીવંત છે, કે તેને restart કરવો જોઈએ?), **readiness** (તે traffic મેળવવા તૈયાર છે?), અને **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.
```

## Probe વ્યાખ્યાઓ

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

startupProbe:            # ધીમા starter ને બીજા શરૂ થાય તે પહેલાં સમય આપે
        httpGet: { path: /healthz, port: 8080 }
        failureThreshold: 30   # 30 * 10s = શરૂ થવા માટે 5 min સુધી
        periodSeconds: 10

readinessProbe:          # traffic ને gate કરો
        httpGet: { path: /ready, port: 8080 }
        initialDelaySeconds: 5
        periodSeconds: 10

livenessProbe:           # unhealthy હોય તો restart કરો
        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 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     # events માં probe failures અને restart કારણો જુઓ
kubectl get pod app          # READY column readiness દર્શાવે; RESTARTS liveness દર્શાવે
```

## આ શા માટે મહત્વનું છે

Health probes એ છે જેના દ્વારા Kubernetes self-healing અને સલામત traffic routing આપે છે, તેથી ત્રણ પ્રકારો અને દરેક ક્યારે વાપરવો તે સમજવું આવશ્યક reliability જ્ઞાન છે. નિર્ણાયક ભેદ — જે ઘણા engineers ને ગૂંચવે છે — એ **readiness** અને **liveness** વચ્ચેનો છે: readiness **traffic** ને નિયંત્રિત કરે છે (નિષ્ફળ થતો Pod Service load-balancer માંથી બહાર ખેંચાય છે પણ ચાલુ રહે છે, જ્યારે તે warm up થઈ રહ્યો હોય કે dependency કામચલાઉ down હોય ત્યારે આદર્શ), જ્યારે liveness **life** ને નિયંત્રિત કરે છે (નિષ્ફળ થતો Pod kill થાય અને restart થાય, જ્યારે તે recovery ની બહાર deadlock થયો હોય ત્યારે). બંનેને ગૂંચવવું — readiness જ્યાં ઇચ્છિત હતું ત્યાં liveness probe વાપરવો — બિનજરૂરી restart loops અને outages સર્જે છે, તેથી દરેક probe કયા પ્રશ્નનો જવાબ આપે છે તે જાણવું સીધું વ્યાવહારિક છે. **startup** probe એક વાસ્તવિક ઐતિહાસિક તકલીફ ઉકેલે છે: ધીમા-boot થતા apps એક વાર liveness પર વિશાળ `initialDelaySeconds` ને ફરજ પાડતા (જે અસલી crashes ની શોધ મોડી કરતું), જ્યારે startup probe boot window ને સુરક્ષિત કરે છે અને liveness/readiness ને ચુસ્ત, સામાન્ય timings સાથે ત્યારે જ ચલાવવા દે છે જ્યારે startup સફળ થાય. probe પદ્ધતિઓ (`httpGet`, `tcpSocket`, `exec`, `grpc`) અને tuning knobs (`initialDelaySeconds`, `periodSeconds`, `failureThreshold`, વગેરે) સમજવાથી તમે health checking ને અનુમાનને બદલે યોગ્ય રીતે configure કરી શકો છો. કારણ કે probes સીધા નક્કી કરે છે કે users healthy Pods સુધી પહોંચે છે કે નહીં અને બગડેલા Pods આપોઆપ recover થાય છે કે નહીં, તેમને યોગ્ય કરવા એ Kubernetes પર reliable, production-grade workloads ચલાવવા માટે પાયાનું છે.

ત્રણ probes એક નજરમાં

Readiness vs liveness — મુખ્ય ભેદ

Probe વ્યાખ્યાઓ

Probe પદ્ધતિઓ

Startup probes શા માટે અસ્તિત્વમાં છે

આ શા માટે મહત્વનું છે

સંબંધિત પ્રશ્નો