Kubernetes Probes
scheduler ကနေ pod ကို worker node တစ်ခု အပေါ်သို့ schedule ပြုလုပ်ပြီးသွားတဲ့အခါ၊ အဲဒီ worker node အပေါ်မှ kubelet သည် containers ကို စတင် run ပါတယ်။ cluster ထဲတွင် အဲဒီ pod တည်ရှိနေသ၍ kubelet က running ဖြစ်ရန် တာဝန် ယူထားရပါတယ်။ container ရဲ့ အဓိက process crashes ဖြစ်လာတဲ့အခါမှာ kubelet က အဲဒီ container ကို restart ပြုလုပ်ပေးပါတယ်။ အဲ့တော့ container ထဲမှာ run နေတဲ့ applications မှာ bug ပါတယ်ဆိုရင် kubernetes က အလိုအလျောက် restart ချပေးနေမှာ ဖြစ်ပါတယ်။ အဲဒီလို crash လိုက် restart ချလိုက် လုံးလည်ချာလည် ဖြစ်နေမှာပါ။ အခုလို ဖြစ်ရတာကတော့ kubernetes ရဲ့heal ပြုလုပ်နိုင်တဲ့ ability ကြောင့် ဖြစ်တယ်။ ဒါပေမဲ့ တချို့အခြေနေတွေမှာ application ရဲ့ process က crash မဖြစ်ဘဲ application က အလုပ်မလုပ်တော့တာတွေ ရှိလာနိုင်ပါတယ်။ ဘယ်လို အခြေနေမျိုးတွေလဲဆိုတော့ ဥပမာ များသောအားဖြင့် java application တွေမှာ memory leak ဖြစ်ပြီး OutOfMemorryError
လိုမျိုး ဖြစ်ပေမဲ့ JVM
process ကတော့ ဆက်လက် running ဖြစ်နေတဲ့ အခြေနေမျိုး ဖြစ်ပါတယ်။ infinite loop ကြောင့်ဖြစ်စေ၊ deadlock ကြောင့်ဖြစ်စေ စတဲ့အခြေနေမျိုး ၂ ခုကြောင့် application က response မလုပ်တော့ဘူးဆိုရင် ကျွန်တော်တို့ ဒီ application ရဲ့ health ကို container အပြင်ကနေ စစ်ဆေးဖို့ လိုလာပါပြီ။ အဲလိုမျိုး စစ်ဆေးတာကို probe လို့ ခေါ်ပါတယ်။ တနည်းအားဖြင့် kubernetes ရဲ့ container တွေကို health check လုပ်ပေးတာ ကို ပြောတာ ဖြစ်ပါတယ်။ probe ကို configure လုပ်ပြီး pod တည်ဆောက်ပြီးတဲ့အခါမှာ kubernetes ရဲ့ kubelet က နေ အဲဒီ probes တွေကို ပုံမှန် သူ့အချိန်နဲ့သူ ပို့လွှတ်ပါတယ်။ အဲလို ပို့လွှတ်ပြီးတဲ့အခါမှာ ဖြစ်နေတဲ့ အခြေအနေပေါ်မူတည်ပြီးတော့ ဘာဆက်လုပ်မယ်ဆိုတာကတော့ probe အမျိုးအစား အပေါ် မူတည်ပြီး ကွဲပြားပါတယ်။ လောလောဆယ် probe ၃ မျိုး ရှိပါတယ်။ ဒါတွေကတော့ -
startup probes (coming soon) ဘဲ ဖြစ်ပါတယ်။
probes အမျိုးအစားတွေက probe လုပ်တာ တူညီကြပေမဲ့ ရည်ရွယ်ချက်တွေ၊ အသုံးပြုမှု ပုံစံတွေ၊ ကတော့ ကွဲပြားပါတယ်။
ဒါကတော့ probe တွေကို yaml နဲ့ ရေးတဲ့ အခါ Container အထဲမှာ ရှိတဲ့ ယေဘုယ probes configuration ပုံစံ ဖြစ်ပါတယ်။
Last updated