liveness, readiness और startup probes क्या हैं, और आप हर एक को कब उपयोग करते हैं?

Question

IT Interview Practice · Accepted Answer

Probes kubelet को किसी container के स्वास्थ्य की जाँच करने और परिणाम पर कार्रवाई करने देते हैं। तीन हैं: **liveness** (क्या यह जीवित है, या इसे restart किया जाना चाहिए?), **readiness** (क्या यह traffic लेने को तैयार है?), और **startup** (क्या इसका boot होना पूरा हुआ?)। हर एक अलग सवाल का जवाब देता है।

## तीन probes एक नज़र में

```text
LIVENESS   → "क्या app अटका/deadlocked है?"      FAIL → kubelet container को RESTART करता है
READINESS  → "क्या यह अभी traffic दे सकता है?"    FAIL → Pod को Service endpoints से हटाया जाता है
                                                       (RESTART नहीं)
STARTUP    → "क्या धीमा boot पूरा हुआ?"           पहले चलता है; जब तक चलता है, liveness व
                                                readiness रोक दिए जाते हैं
```

## Readiness बनाम liveness — मुख्य अंतर

```text
Readiness TRAFFIC को नियंत्रित करता है:
  → जो Pod readiness में fail होता है उसे Service load-balancer से बाहर निकाला जाता है,
    पर वह चलता रहता है (जैसे यह cache warm कर रहा हो या कोई dependency down हो)
Liveness LIFE को नियंत्रित करता है:
  → जो Pod liveness में fail होता है उसे मारकर restart किया जाता है (यह ठीक होने से परे टूटा है)
जहाँ आपका मतलब readiness था वहाँ liveness का उपयोग बेवजह 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 मिनट तक
        periodSeconds: 10

readinessProbe:          # traffic को gate करें
        httpGet: { path: /ready, port: 8080 }
        initialDelaySeconds: 5
        periodSeconds: 10

livenessProbe:           # अस्वस्थ हो तो restart करें
        httpGet: { path: /healthz, port: 8080 }
        periodSeconds: 10
        failureThreshold: 3
```

## Probe क्रियाविधियाँ

```text
httpGet    → किसी path को GET करें; 2xx/3xx = pass   (web apps के लिए सबसे आम)
tcpSocket  → क्या हम एक TCP connection खोल सकते हैं?   (गैर-HTTP services के लिए)
exec       → एक command चलाएँ; exit 0 = pass          (कस्टम जाँच)
grpc       → native gRPC health check
मुख्य knobs: initialDelaySeconds, periodSeconds, timeoutSeconds,
           failureThreshold, successThreshold।
```

## Startup probes क्यों मौजूद हैं

```text
धीमे-शुरू होने वाले apps (JVM warmup, बड़े migrations) पहले आपको liveness पर एक बहुत बड़ा
initialDelaySeconds सेट करने को मजबूर करते थे — जिससे फिर असली crashes का पता लगना धीमा हो जाता।
startupProbe इसे ठीक करता है: यह धीमे boot की रक्षा करता है, और केवल इसके pass होने के बाद ही
liveness/readiness अपने सामान्य (कसे) 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 देता है, इसलिए तीन प्रकारों और हर एक को कब उपयोग करें यह समझना आवश्यक विश्वसनीयता ज्ञान है। महत्वपूर्ण अंतर — जो कई इंजीनियरों को फँसाता है — **readiness** और **liveness** के बीच है: readiness **traffic** को नियंत्रित करता है (एक fail होता Pod Service load-balancer से बाहर निकाला जाता है पर चलता रहता है, जो तब आदर्श है जब वह warm हो रहा हो या कोई dependency अस्थायी रूप से down हो), जबकि liveness **life** को नियंत्रित करता है (एक fail होता Pod मारकर restart किया जाता है, जब वह ठीक होने से परे deadlocked हो)। दोनों को भ्रमित करना — जहाँ readiness का मतलब था वहाँ liveness probe उपयोग करना — बेवजह restart loops और outages पैदा करता है, इसलिए यह जानना कि हर probe किस सवाल का जवाब देता है, सीधे व्यावहारिक है। **startup** probe एक असली ऐतिहासिक तकलीफ़ हल करता है: धीमे-boot होते apps पहले liveness पर विशाल `initialDelaySeconds` को मजबूर करते थे (जो असली crashes का पता लगने में देरी करता), जबकि एक startup probe boot खिड़की की रक्षा करता है और liveness/readiness को कसे, सामान्य timings के साथ केवल तभी चलने देता है जब startup सफल हो जाए। probe क्रियाविधियों (`httpGet`, `tcpSocket`, `exec`, `grpc`) और tuning knobs (`initialDelaySeconds`, `periodSeconds`, `failureThreshold`, आदि) को समझना आपको health checking को अनुमान के बजाय सही ढंग से configure करने देता है। चूँकि probes सीधे तय करते हैं कि उपयोगकर्ता स्वस्थ Pods तक पहुँचें और टूटे Pods स्वतः recover हों, इन्हें सही करना Kubernetes पर विश्वसनीय, production-ग्रेड workloads चलाने की नींव है।

तीन probes एक नज़र में

Readiness बनाम liveness — मुख्य अंतर

Probe परिभाषाएँ

Probe क्रियाविधियाँ

Startup probes क्यों मौजूद हैं

यह क्यों महत्वपूर्ण है

संबंधित प्रश्न