Liveness, readiness, र startup probe के हुन्, र प्रत्येक कहिले प्रयोग गर्नुहुन्छ?

Question

IT Interview Practice · Accepted Answer

Probe हरूले kubelet लाई container को स्वास्थ्य जाँच्न र नतिजामा कदम चाल्न दिन्छन्। तीन वटा छन्: **liveness** (यो जीवित छ, वा restart गर्नुपर्छ?), **readiness** (यो traffic लिन तयार छ?), र **startup** (यसले boot सकिसक्यो?)। प्रत्येकले फरक प्रश्नको जवाफ दिन्छ।

## तीन 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 बनाम 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 मिनेट
        periodSeconds: 10

readinessProbe:          # traffic नियन्त्रण गर्नुहोस्
        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 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     # events मा probe failure र restart कारण हेर्नुहोस्
kubectl get pod app          # READY column ले readiness झल्काउँछ; RESTARTS ले liveness
```

## यो किन महत्त्वपूर्ण छ

Health probe हरू नै Kubernetes ले self-healing र सुरक्षित traffic routing दिने तरिका हुन्, त्यसैले तीन प्रकार र प्रत्येक कहिले प्रयोग गर्ने भन्ने बुझ्नु अत्यावश्यक reliability ज्ञान हो। महत्त्वपूर्ण भिन्नता — जसले धेरै इन्जिनियरलाई अल्झाउँछ — **readiness** र **liveness** बीचको हो: readiness ले **traffic** नियन्त्रण गर्छ (फेल हुने Pod Service load-balancer बाट निकालिन्छ तर चलिरहन्छ, जुन यो warm up हुँदै छ वा dependency क्षणिक रूपमा down छ भने आदर्श हुन्छ), भने liveness ले **जीवन** नियन्त्रण गर्छ (फेल हुने Pod मारिन्छ र restart हुन्छ, जब यो पुनःप्राप्ति नहुने गरी बिग्रिएको हुन्छ)। यी दुई अलमल्याउनु — readiness चाहिने ठाउँमा liveness probe प्रयोग गर्नु — अनावश्यक restart loop र outage निम्त्याउँछ, त्यसैले प्रत्येक probe ले कुन प्रश्नको जवाफ दिन्छ भन्ने थाहा पाउनु सिधै व्यावहारिक हो। **Startup** probe ले एउटा वास्तविक ऐतिहासिक पीडा समाधान गर्छ: ढिलो-boot हुने एपले पहिले liveness मा ठूलो `initialDelaySeconds` सेट गर्न बाध्य पार्थ्यो (जसले वास्तविक crash पत्ता लगाउन ढिलो बनाउँथ्यो), भने startup probe ले boot window लाई जोगाउँछ र startup सफल भएपछि मात्र liveness/readiness लाई कस्सिएका, सामान्य timing सँग चलाउन दिन्छ। Probe संयन्त्रहरू (`httpGet`, `tcpSocket`, `exec`, `grpc`) र tuning knob हरू (`initialDelaySeconds`, `periodSeconds`, `failureThreshold`, आदि) बुझ्नाले तपाईंलाई अनुमानले होइन सही तरिकाले health checking configure गर्न दिन्छ। Probe हरूले प्रयोगकर्ताले स्वस्थ Pod भेट्छन् कि भन्ने र बिग्रिएका Pod स्वतः पुनःप्राप्त हुन्छन् कि भन्ने सिधै निर्धारण गर्ने हुनाले, तिनलाई सही पार्नु Kubernetes मा भरपर्दो, production-स्तरको workload चलाउने आधारभूत कुरा हो।

तीन probe एक नजरमा

Readiness बनाम liveness — मुख्य भिन्नता

Probe परिभाषा

Probe संयन्त्रहरू

Startup probe किन अस्तित्वमा छन्

यो किन महत्त्वपूर्ण छ

सम्बन्धित प्रश्नहरू