liveness، readiness، اور startup probes کیا ہیں، اور آپ ہر ایک کو کب استعمال کرتے ہیں؟

Question

IT Interview Practice · Accepted Answer

Probes، kubelet کو ایک container کی صحت جانچنے اور نتیجے پر عمل کرنے دیتے ہیں۔ تین ہیں: **liveness** (کیا یہ زندہ ہے، یا اسے restart کیا جانا چاہیے؟)، **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 بمقابلہ 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 * 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
```

## 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 کی ناکامیاں اور restart کی وجوہات دیکھیں
kubectl get pod app          # READY کالم readiness ظاہر کرتا ہے؛ RESTARTS liveness ظاہر کرتا ہے
```

## یہ کیوں اہم ہے

Health probes وہ طریقہ ہیں جس سے Kubernetes self-healing اور محفوظ ٹریفک routing فراہم کرتا ہے، اس لیے تینوں اقسام اور ہر ایک کو کب استعمال کرنا ہے، اسے سمجھنا ایک ضروری اعتباریت (reliability) کا علم ہے۔ اہم فرق — جو بہت سے انجینئرز کو گراتا ہے — **readiness** اور **liveness** کے درمیان ہے: readiness **ٹریفک** کو کنٹرول کرتا ہے (ایک ناکام Pod کو Service load-balancer سے باہر نکال دیا جاتا ہے مگر وہ چلتا رہتا ہے، جو اُس وقت مثالی ہے جب وہ گرم ہو رہا ہو یا کوئی dependency عارضی طور پر بند ہو)، جبکہ liveness **زندگی** کو کنٹرول کرتا ہے (ایک ناکام Pod کو مار کر restart کیا جاتا ہے، اُس وقت کے لیے جب وہ بحالی سے ماورا deadlock میں ہو)۔ دونوں کو گڈمڈ کرنا — جہاں readiness مقصود تھا وہاں liveness probe استعمال کرنا — بلاوجہ restart loops اور outages کا سبب بنتا ہے، اس لیے یہ جاننا کہ ہر probe کس سوال کا جواب دیتا ہے، براہِ راست عملی ہے۔ **startup** probe ایک حقیقی تاریخی تکلیف کو حل کرتا ہے: سست boot ہونے والی ایپس کبھی liveness پر بڑا `initialDelaySeconds` مقرر کرنے پر مجبور کرتی تھیں (جو حقیقی crashes کی نشاندہی میں تاخیر کر دیتا تھا)، جبکہ startup probe boot کی کھڑکی کی حفاظت کرتا ہے اور liveness/readiness کو صرف startup کے کامیاب ہونے کے بعد ہی سخت، عام timings کے ساتھ چلنے دیتا ہے۔ probe کے طریقہ کار (`httpGet`، `tcpSocket`، `exec`، `grpc`) اور tuning knobs (`initialDelaySeconds`، `periodSeconds`، `failureThreshold`، وغیرہ) کو سمجھنا آپ کو health checking کو اندازے کے بجائے درست طریقے سے کنفیگر کرنے دیتا ہے۔ چونکہ probes براہِ راست طے کرتے ہیں کہ آیا صارفین صحت مند Pods تک پہنچتے ہیں اور آیا خراب Pods خود بخود بحال ہوتے ہیں، انہیں درست کرنا Kubernetes پر قابلِ اعتماد، production-گریڈ workloads چلانے کے لیے بنیادی ہے۔

تینوں probes ایک نظر میں

Readiness بمقابلہ liveness — کلیدی فرق

Probe کی تعریفات

Probe کے طریقہ کار

Startup probes کیوں موجود ہیں

یہ کیوں اہم ہے

متعلقہ سوالات