Liveness, readiness, ও startup probe কী, এবং প্রতিটি কখন ব্যবহার করবেন?

Question

IT Interview Practice · Accepted Answer

Probe kubelet-কে একটি container-এর স্বাস্থ্য পরীক্ষা করতে এবং ফলাফলের উপর ভিত্তি করে কাজ করতে দেয়। তিনটি আছে: **liveness** (এটি কি জীবিত, নাকি restart করা উচিত?), **readiness** (এটি কি ট্রাফিক গ্রহণে প্রস্তুত?), এবং **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 = শুরু হতে সর্বোচ্চ ৫ মিনিট
        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 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     # event-এ probe failure ও restart কারণ দেখুন
kubectl get pod app          # READY কলাম readiness প্রতিফলিত করে; RESTARTS liveness
```

## এটি কেন গুরুত্বপূর্ণ

Health probe হলো যেভাবে Kubernetes self-healing ও নিরাপদ ট্রাফিক routing সরবরাহ করে, তাই তিনটি প্রকার এবং প্রতিটি কখন ব্যবহার করবেন তা বোঝা অপরিহার্য নির্ভরযোগ্যতা জ্ঞান। গুরুত্বপূর্ণ পার্থক্যটি — যা অনেক ইঞ্জিনিয়ারকে হোঁচট খাওয়ায় — **readiness** ও **liveness**-এর মধ্যে: readiness **ট্রাফিক** নিয়ন্ত্রণ করে (একটি ব্যর্থ Pod Service load-balancer থেকে টেনে বের করা হয় কিন্তু চলতে থাকে, আদর্শ যখন এটি warm up হচ্ছে বা একটি dependency সাময়িকভাবে down), যখন liveness **জীবন** নিয়ন্ত্রণ করে (একটি ব্যর্থ Pod মেরে ফেলা ও restart করা হয়, যখন এটি পুনরুদ্ধারের বাইরে deadlocked)। দুটি গুলিয়ে ফেলা — যেখানে readiness বোঝানো হয়েছিল সেখানে একটি liveness probe ব্যবহার করা — অপ্রয়োজনীয় restart loop ও outage ঘটায়, তাই প্রতিটি probe কোন প্রশ্নের উত্তর দেয় তা জানা সরাসরি ব্যবহারিক। **startup** probe একটি বাস্তব ঐতিহাসিক যন্ত্রণা সমাধান করে: ধীর-boot হওয়া অ্যাপ একসময় liveness-এ বিশাল `initialDelaySeconds` বাধ্য করত (যা প্রকৃত crash সনাক্তকরণ দেরি করত), যেখানে একটি startup probe boot window রক্ষা করে এবং liveness/readiness-কে কেবল startup সফল হওয়ার পরেই নিবিড়, স্বাভাবিক timing নিয়ে চলতে দেয়। probe প্রক্রিয়া (`httpGet`, `tcpSocket`, `exec`, `grpc`) ও tuning knob (`initialDelaySeconds`, `periodSeconds`, `failureThreshold`, ইত্যাদি) বোঝা আপনাকে অনুমানের বদলে সঠিকভাবে health checking কনফিগার করতে দেয়। যেহেতু probe সরাসরি নির্ধারণ করে ব্যবহারকারীরা সুস্থ Pod-এ পৌঁছায় কিনা এবং ভাঙা Pod স্বয়ংক্রিয়ভাবে পুনরুদ্ধার হয় কিনা, এদের সঠিক করা Kubernetes-এ নির্ভরযোগ্য, production-গ্রেড workload চালানোর জন্য ভিত্তিমূলক।

এক নজরে তিনটি probe

Readiness বনাম liveness — মূল পার্থক্য

Probe সংজ্ঞা

Probe প্রক্রিয়া

কেন startup probe থাকে

এটি কেন গুরুত্বপূর্ণ

সম্পর্কিত প্রশ্ন