ခဏလေး ဒီလိုပဲ စဉ်းစားကြည့်
Pod status အမျိုးမျိုး ရှိပါတယ် — Pending (scheduler က node ရှာမရသေး, ဒါမှမဟုတ် image pull လုပ်နေဆဲ), CrashLoopBackOff (container crash ဖြစ်ပြီးပြီး restart ထပ်ခါထပ်ခါ crash ဖြစ်နေခြင်း), ImagePullBackOff (image ကို registry ကနေ download မရခြင်း)။ `kubectl describe pod` က Event log ကို ပြပေးပြီး ဘာဖြစ်နေလဲ context ပေးပါတယ်။ `kubectl logs` က container ရဲ့ stdout/stderr output ကို ကြည့်နိုင်ပြီး, application-level error (code exception, config missing) ကို ရှာနိုင်ပါတယ်။ `kubectl exec -it <pod> -- /bin/sh` က pod ထဲကို တိုက်ရိုက်ဝင်ပြီး interactive debug လုပ်နိုင်ပါတယ် (container crash ခဏတာသာ run ရင် exec မဝင်နိုင်တာလည်း ဖြစ်နိုင်ပါတယ်).
လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်
CrashLoopBackOff ကို တွေ့ရင် ပထမဆုံး `kubectl logs <pod-name> --previous` (ပျက်သွားခဲ့တဲ့ container ရဲ့ log) ကို ကြည့်ပါ — မှားနေတဲ့ config, connection error, port already in use စတဲ့ error message များ ပြသင့်ပါတယ်။ ImagePullBackOff ဆိုရင် `kubectl describe pod` ရဲ့ Event ထဲမှာ image name typo/registry authentication error ကို ရှာတွေ့နိုင်ပါတယ်.
အတူတူ ကြည့်မယ်
# See why a pod isn't starting
kubectl describe pod <pod-name>
# See its logs
kubectl logs <pod-name>
# See logs from a crashed container's previous run
kubectl logs <pod-name> --previous
# Get an interactive shell inside a running pod
kubectl exec -it <pod-name> -- /bin/sh
# Watch pod status change in real time
kubectl get pods --watchEvents:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning Failed 10s kubelet Failed to pull image "my-app:v99": not found၅ မိနစ် စမ်းကြည့်
Image name ကို မှားရေးထားတဲ့ Pod တစ်ခု (ဥပမာ `image: my-app:does-not-exist`) create လုပ်ကြည့်ပါ — `kubectl describe pod` နဲ့ ImagePullBackOff error ကို ရှာတွေ့အောင် debug ကြည့်ပါ။
သတိလေးတစ်ချက်
`kubectl exec` နဲ့ pod ထဲဝင်ပြီး live production container ထဲမှာ file/config ကို manual ပြင်ခြင်းက temporary fix ပဲ ဖြစ်ပါတယ် — pod ပြန် create ရင် (rolling update, crash) အားလုံးပျောက်သွားမှာမို့ root cause ကို YAML/code level မှာ ပြင်ရပါမယ်။