ခဏလေး ဒီလိုပဲ စဉ်းစားကြည့်
Container process က crash မဖြစ်ပေမယ့် app ကတော့ deadlock ဖြစ်နေတာမျိုး (request ကို response ပြန်မပေးနိုင်တော့) ဖြစ်နိုင်ပါတယ် — Kubernetes အမြင်မှာတော့ container က 'Running' ပဲ ဆက်ပြနေမှာပါ (process ကတော့ live နေဆဲမို့)။ Liveness Probe က 'app က တကယ်အလုပ်လုပ်နေလား' ကို periodic check လုပ်ပြီး, fail ဖြစ်ရင် container ကို restart လုပ်ပေးပါတယ်။ Readiness Probe ကတော့ 'app က traffic လက်ခံဖို့ အသင့်ဖြစ်ပြီလား' ကို check လုပ်ပြီး, fail ဖြစ်နေရင် Service က အဲဒီ pod ဆီ traffic မပို့ဘဲ ခဏစောင့်ပေးပါတယ် (container startup slow ဖြစ်တဲ့ app အတွက် အထူး အသုံးဝင်ပါတယ်).
လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်
Web app မှာ `/healthz` ဆိုတဲ့ endpoint တစ်ခု ရေးထားပြီး, Liveness Probe က HTTP request ကို ၁၀ စက္ကန့်တစ်ခါ ပို့ကြည့်ပါတယ် — response 200 မရရင် container ကို restart ပါတယ်။ Database connection pool setup ကြာတဲ့ app တစ်ခုမှာ Readiness Probe ထားရင်, startup ကြာနေချိန် Service က traffic မပို့ဘဲ setup ပြီးမှ traffic ပို့ပေးမှာပါ — user တွေ error မတွေ့ရအောင် ကာကွယ်ပေးတာပါ။
အတူတူ ကြည့်မယ်
apiVersion: v1
kind: Pod
metadata:
name: web-with-probes
spec:
containers:
- name: web
image: my-app:latest
livenessProbe:
httpGet:
path: /healthz
port: 8080
periodSeconds: 10
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 5$ kubectl describe pod web-with-probes
...
Liveness: http-get http://:8080/healthz delay=0s timeout=1s period=10s
Readiness: http-get http://:8080/ready delay=5s timeout=1s period=5s၅ မိနစ် စမ်းကြည့်
Liveness/Readiness probe ၂ ခုစလုံး ပါတဲ့ pod တစ်ခု YAML ရေးပြီး apply လုပ်ကြည့်ပါ — `kubectl describe pod` နဲ့ probe config ကို confirm လုပ်ကြည့်ပါ။
သတိလေးတစ်ချက်
Liveness Probe နဲ့ Readiness Probe ကို endpoint တစ်ခုတည်း မသုံးပါနှင့် — Liveness က 'ငါအသက်ရှင်နေလား' (light check), Readiness က 'ငါ traffic လက်ခံနိုင်ပြီလား' (dependency check ပါ ပါနိုင်) ဆိုတဲ့ ရည်ရွယ်ချက် မတူပါ။