Kubernetes အကောင်းဆုံး အလေ့အကျင့်များ။ အဆင်သင့် နှင့် အသက်ရှင်မှု စမ်းသပ်မှုများဖြင့် Kubernetes Liveness ကို အတည်ပြုခြင်း

Kubernetes အကောင်းဆုံး အလေ့အကျင့်များ။ ကွန်တိန်နာငယ်များ ဖန်တီးခြင်း။
Kubernetes အကောင်းဆုံး အလေ့အကျင့်များ။ Namespace ဖြင့် Kubernetes ၏အဖွဲ့အစည်း

ဖြန့်ဝေထားသောစနစ်များသည် စနစ်လည်ပတ်ရန်အတွက်စနစ်တကျလုပ်ဆောင်ရန် လိုအပ်သည့်ရွေ့လျားပြောင်းလဲနေသောဒြပ်စင်များစွာရှိသောကြောင့် စီမံခန့်ခွဲရန်ခက်ခဲနိုင်သည်။ ဒြပ်စင်များထဲမှ တစ်ခု ပျက်ကွက်ပါက၊ စနစ်က ၎င်းကို ထောက်လှမ်းပြီး ၎င်းကို ကျော်ဖြတ်ကာ ပြုပြင်ရမည် ဖြစ်ပြီး ၎င်းအားလုံးကို အလိုအလျောက် လုပ်ဆောင်ရမည်ဖြစ်သည်။ ဤ Kubernetes အကောင်းဆုံးအလေ့အကျင့်စီးရီးများတွင် Kubernetes အစုအဝေး၏ကျန်းမာရေးကို စမ်းသပ်ရန်အတွက် အဆင်သင့်နှင့် ရှင်သန်မှုဆိုင်ရာစစ်ဆေးမှုများကို မည်သို့သတ်မှတ်ရမည်ကို ကျွန်ုပ်တို့ လေ့လာပါမည်။

Health Check သည် သင့်အပလီကေးရှင်း၏ စံနမူနာကို လည်ပတ်နေသလား၊ မလုပ်ဆောင်ကြောင်း စနစ်အား အသိပေးရန် ရိုးရှင်းသောနည်းလမ်းတစ်ခုဖြစ်သည်။ သင်၏ အက်ပ်လီကေးရှင်း လုပ်ဆောင်ချက် ပျက်သွားပါက၊ အခြား ဝန်ဆောင်မှုများက ၎င်းကို ဝင်ရောက်ခြင်း သို့မဟုတ် ၎င်းထံ တောင်းဆိုမှုများ မပို့သင့်ပါ။ ယင်းအစား၊ တောင်းဆိုချက်ကို လုပ်ဆောင်နေပြီး သို့မဟုတ် နောက်ပိုင်းတွင် စတင်မည့် အပလီကေးရှင်း၏ အခြားဥပမာသို့ ပေးပို့ရမည်ဖြစ်သည်။ ထို့အပြင်၊ စနစ်သည် သင့်အပလီကေးရှင်း၏ ဆုံးရှုံးသွားသော လုပ်ဆောင်နိုင်စွမ်းကို ပြန်လည်ရယူသင့်သည်။

ပုံသေအားဖြင့်၊ Pods အတွင်းရှိ ကွန်တိန်နာများ လည်ပတ်နေချိန်တွင်၊ Kubernetes သည် လမ်းကြောင်းတစ်ခုသို့ အသွားအလာကို စတင်ပေးပို့မည်ဖြစ်ပြီး ၎င်းတို့ ပျက်စီးသွားသည့်အခါ ကွန်တိန်နာများကို ပြန်လည်စတင်မည်ဖြစ်သည်။ ဤမူလစနစ်အမူအကျင့်သည် စတင်ရန် လုံလောက်သော်လည်း စိတ်ကြိုက်စိတ်သန့်သန့်စစ်ဆေးမှုများကို အသုံးပြုခြင်းဖြင့် သင့်ထုတ်ကုန်ဖြန့်ကျက်မှု၏ ယုံကြည်စိတ်ချရမှုကို မြှင့်တင်နိုင်ပါသည်။

ကံကောင်းထောက်မစွာ၊ Kubernetes သည် ၎င်းကိုလုပ်ဆောင်ရန်အတော်လေးလွယ်ကူစေသည်၊ ထို့ကြောင့် ဤစစ်ဆေးမှုများကိုလျစ်လျူရှုရန်အကြောင်းပြချက်မရှိပါ။ Kubernetes သည် ကျန်းမာရေးစစ်ဆေးမှု အမျိုးအစား နှစ်မျိုးကို ပံ့ပိုးပေးထားပြီး တစ်ခုချင်းစီကို အသုံးပြုပုံ ကွာခြားချက်များကို နားလည်ရန် အရေးကြီးပါသည်။

သင့်အပလီကေးရှင်းသည် ယာဉ်ကြောအသွားအလာကို ကိုင်တွယ်ရန် အဆင်သင့်ဖြစ်နေပြီဟု Kubernetes အား ပြောပြရန် အဆင်သင့်စစ်ဆေးမှုကို ဒီဇိုင်းထုတ်ထားသည်။ ဝန်ဆောင်မှုတစ်ခုအား pod တစ်ခုသို့ အသွားအလာပို့ရန် ခွင့်ပြုခြင်းမပြုမီ၊ အဆင်သင့်စစ်ဆေးမှု အောင်မြင်ကြောင်း Kubernetes မှ အတည်ပြုရပါမည်။ အဆင်သင့်စမ်းသပ်မှု မအောင်မြင်ပါက၊ စမ်းသပ်မှုမပြီးမချင်း Kubernetes သည် pod သို့ အသွားအလာပေးပို့ခြင်းကို ရပ်သွားပါမည်။

Liveness test သည် သင်၏ အက်ပ်လီကေးရှင်း အသက်ရှင်သည် သို့မဟုတ် သေဆုံးခြင်းရှိမရှိ Kubernetes အား ပြောပြသည်။ ပထမကိစ္စတွင်၊ Kubernetes သည် ၎င်းကို တစ်ယောက်တည်းထားခဲ့မည်ဖြစ်ပြီး၊ ဒုတိယတွင် ၎င်းသည် dead pod ကိုဖျက်ကာ အသစ်တစ်ခုနှင့်အစားထိုးမည်ဖြစ်သည်။

သင့်အပလီကေးရှင်းကို နွေးထွေးစေပြီး စတင်ရန် ၁ မိနစ်ကြာသည့် မြင်ကွင်းတစ်ခုကို စိတ်ကူးကြည့်ကြပါစို့။ အလုပ်အသွားအလာ စတင်နေပြီဖြစ်သော်လည်း၊ အပလီကေးရှင်းကို အပြည့်အ၀ တင်ပြီး မလည်ပတ်မချင်း သင့်ဝန်ဆောင်မှုသည် အလုပ်မလုပ်တော့ပါ။ ဤကော်ပီအများအပြားကို ဖြန့်ကျက်ချဲ့ထွင်လိုပါကလည်း ပြဿနာရှိနိုင်သည်၊ သို့သော်လည်း ပုံမှန်အားဖြင့်၊ ကွန်တိန်နာအတွင်း လုပ်ငန်းစဉ်များစတင်သည်နှင့်တပြိုင်နက် Kubernetes သည် အသွားအလာစတင်ပေးပို့မည်ဖြစ်သည်။

အဆင်သင့်စမ်းသပ်မှုကို အသုံးပြုသည့်အခါ၊ ဝန်ဆောင်မှုကို မိတ္တူအသစ်သို့ လမ်းကြောင်းများပေးပို့ခြင်းမပြုမီ အပလီကေးရှင်းကို အပြည့်အဝလည်ပတ်သည့်အချိန်အထိ Kubernetes က စောင့်ပါမည်။

အပလီကေးရှင်းကို အချိန်အကြာကြီးဆွဲထားကာ ဝန်ဆောင်မှုတောင်းဆိုမှုများကို ရပ်တန့်စေသည့် အခြားဇာတ်လမ်းတစ်ခုကို စိတ်ကူးကြည့်ကြပါစို့။ လုပ်ငန်းစဉ် ဆက်လက်လည်ပတ်နေသဖြင့်၊ မူရင်း Kubernetes သည် အရာအားလုံးအဆင်ပြေသည်ဟု ယူဆပြီး အလုပ်မလုပ်သော pod သို့ တောင်းဆိုမှုများကို ဆက်လက်ပေးပို့ပါမည်။ သို့သော် Liveness ကိုအသုံးပြုသောအခါတွင်၊ အပလီကေးရှင်းသည် တောင်းဆိုချက်များကိုမဆောင်ရွက်ပေးတော့ကြောင်း Kubernetes မှသိရှိပြီး dead pod ကို မူရင်းအတိုင်းပြန်လည်စတင်မည်ဖြစ်သည်။

အဆင်သင့် နှင့် ရှင်သန်နိုင်စွမ်းကို စမ်းသပ်ကြည့်ကြပါစို့။ HTTP၊ Command နှင့် TCP စမ်းသပ်နည်းသုံးမျိုးရှိသည်။ စစ်ဆေးရန် ၎င်းတို့ကို သင်အသုံးပြုနိုင်သည်။ အသုံးပြုသူအား စမ်းသပ်ရန် အသုံးအများဆုံးနည်းလမ်းမှာ HTTP probe ဖြစ်သည်။

သင့်အပလီကေးရှင်းသည် HTTP ဆာဗာမဟုတ်သော်လည်း၊ Liveness စမ်းသပ်မှုနှင့် အပြန်အလှန်တုံ့ပြန်ရန်အတွက် သင့်အပလီကေးရှင်းအတွင်း၌ ပေါ့ပါးသော HTTP ဆာဗာကို သင်ဖန်တီးနိုင်သေးသည်။ ၎င်းပြီးနောက်၊ Kubernetes သည် pod ကို စတင် ping လုပ်မည်ဖြစ်ပြီး HTTP တုံ့ပြန်မှုသည် 200 သို့မဟုတ် 300 ms အကွာအဝေးတွင်ရှိနေပါက၊ pod သည် ကျန်းမာကြောင်း ညွှန်ပြလိမ့်မည်။ မဟုတ်ပါက၊ သင်ခန်းစာအား "မကျန်းမာ" ဟု အမှတ်အသားပြုပါမည်။

ကွပ်ကဲမှုစမ်းသပ်မှုများအတွက် Kubernetes သည် သင့်ကွန်တိန်နာအတွင်းရှိ အမိန့်ကို လုပ်ဆောင်သည်။ အမိန့်သည် သုညထွက်ပေါက်ကုဒ်ဖြင့် ပြန်ဝင်လာပါက၊ ကွန်တိန်နာကို ကျန်းမာသောအဖြစ် အမှတ်အသားပြုမည်၊ သို့မဟုတ်ပါက ထွက်ပေါက်အခြေအနေနံပါတ် 1 မှ 255 အထိ လက်ခံရရှိသောအခါ၊ ကွန်တိန်နာကို "နာမကျန်း" အဖြစ် အမှတ်အသားပြုမည်ဖြစ်သည်။ HTTP ဆာဗာကို မလုပ်ဆောင်နိုင် သို့မဟုတ် မလုပ်ဆောင်လိုပါက ဤစမ်းသပ်မှုနည်းလမ်းသည် အသုံးဝင်သော်လည်း သင့်အပလီကေးရှင်း၏ ကျန်းမာရေးကို စစ်ဆေးပေးမည့် command တစ်ခုကို လုပ်ဆောင်နိုင်သည်။

နောက်ဆုံးအတည်ပြုခြင်းယန္တရားမှာ TCP စမ်းသပ်မှုဖြစ်သည်။ Kubernetes သည် သတ်မှတ်ထားသော အပေါက်တွင် TCP ချိတ်ဆက်မှုတစ်ခုကို တည်ဆောက်ရန် ကြိုးစားပါမည်။ ထိုသို့လုပ်ဆောင်နိုင်လျှင် ကွန်တိန်နာကို ကျန်းမာရေးနှင့်ညီညွတ်သည်ဟု ယူဆသည်၊ မဟုတ်ပါက၊ ၎င်းကို အသုံးမပြုနိုင်ဟု ယူဆပါသည်။ HTTP တောင်းဆိုချက် သို့မဟုတ် အမိန့်ပေးသည့် လုပ်ဆောင်မှု ကောင်းစွာအလုပ်မလုပ်သည့် မြင်ကွင်းတစ်ခုကို သင်အသုံးပြုနေပါက ဤနည်းလမ်းသည် အသုံးဝင်နိုင်သည်။ ဥပမာအားဖြင့်၊ TCP ကိုအသုံးပြု၍ အတည်ပြုခြင်းအတွက် အဓိကဝန်ဆောင်မှုများသည် gRPC သို့မဟုတ် FTP ဖြစ်လိမ့်မည်။

စမ်းသပ်မှုများကို မတူညီသော ကန့်သတ်ချက်များဖြင့် နည်းလမ်းများစွာဖြင့် ပြင်ဆင်သတ်မှတ်နိုင်သည်။ ၎င်းတို့ကို မည်မျှလုပ်ဆောင်သင့်သည်၊ အောင်မြင်မှုနှင့် ကျရှုံးမှုအဆင့်သတ်မှတ်ချက်များနှင့် တုံ့ပြန်မှုများကို မည်မျှကြာကြာစောင့်ရမည်ကို သင်သတ်မှတ်နိုင်ပါသည်။ ပိုမိုသိရှိလိုပါက၊ အဆင်သင့်နှင့် အသက်ရှင်မှုစမ်းသပ်မှုများအတွက် စာရွက်စာတမ်းများကို ကြည့်ပါ။ သို့သော်၊ Liveness test ကိုတည်ဆောက်ရာတွင် အလွန်အရေးကြီးသောအချက်တစ်ခုရှိသည် - စမ်းသပ်မှုနှောင့်နှေးမှု initialDelaySeconds ၏ ကနဦးဆက်တင်။ ငါပြောခဲ့သည့်အတိုင်း၊ ဤစမ်းသပ်မှုမအောင်မြင်ပါက module ကိုပြန်လည်စတင်မည်ဖြစ်သည်။ ထို့ကြောင့် အပလီကေးရှင်းကို အဆင်သင့်မဖြစ်မချင်း စမ်းသပ်ခြင်းမစတင်ကြောင်း သေချာစေရန်လိုအပ်ပြီး၊ သို့မဟုတ်ပါက ၎င်းသည် ပြန်လည်စတင်ခြင်းမှတစ်ဆင့် စက်ဘီးစီးခြင်းစတင်မည်ဖြစ်သည်။ P99 စတင်ချိန် သို့မဟုတ် ကြားခံမှ ပျမ်းမျှအပလီကေးရှင်းစတင်ချိန်ကို အသုံးပြုရန် ကျွန်ုပ်အကြံပြုပါသည်။ သင့်အပလီကေးရှင်း၏စတင်ချိန်ပိုမြန်သည် သို့မဟုတ် နှေးသွားသဖြင့် ဤတန်ဖိုးကို ချိန်ညှိရန် မမေ့ပါနှင့်။

ကျွမ်းကျင်သူအများစုသည် ကျန်းမာရေးစစ်ဆေးမှုများသည် ဖြန့်ဝေသည့်စနစ်အတွက် မရှိမဖြစ်စစ်ဆေးမှုဖြစ်ကြောင်း အတည်ပြုမည်ဖြစ်ပြီး Kubernetes သည် ချွင်းချက်မဟုတ်ပါ။ ဝန်ဆောင်မှုကျန်းမာရေးစစ်ဆေးမှုများကို အသုံးပြုခြင်းဖြင့် Kubernetes ၏ ယုံကြည်စိတ်ချရသော၊ ပြဿနာကင်းသည့် လုပ်ဆောင်ချက်ကို သေချာစေပြီး အသုံးပြုသူများအတွက် လွယ်ကူသည်။

မကြာမီ ဆက်လက်ဖော်ပြပါမည်...

ကြော်ငြာအချို့ 🙂

ကျွန်ုပ်တို့နှင့်အတူရှိနေသည့်အတွက် ကျေးဇူးတင်ပါသည်။ ကျွန်ုပ်တို့၏ဆောင်းပါးများကို သင်နှစ်သက်ပါသလား။ ပိုစိတ်ဝင်စားစရာကောင်းတဲ့ အကြောင်းအရာတွေကို ကြည့်ချင်ပါသလား။ မှာယူမှုတစ်ခုပြုလုပ်ခြင်း သို့မဟုတ် သူငယ်ချင်းများကို အကြံပြုခြင်းဖြင့် ကျွန်ုပ်တို့အား ပံ့ပိုးကူညီပါ၊ $4.99 မှ developer များအတွက် cloud VPS, မင်းအတွက် ငါတို့က တီထွင်ထားတဲ့ entry-level server တွေရဲ့ ထူးခြားတဲ့ analogue တစ်ခု။ VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps သို့မဟုတ် $19 မှ ဆာဗာတစ်ခုမျှဝေပုံနှင့်ပတ်သက်သော အမှန်တရားတစ်ခုလုံး။ (RAID1 နှင့် RAID10၊ 24 cores အထိနှင့် 40GB DDR4 အထိ)။

အမ်စတာဒမ်ရှိ Equinix Tier IV ဒေတာစင်တာတွင် Dell R730xd သည် ၂ ဆ စျေးသက်သာသည်။ ဒီမှာသာ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV ကို $199 မှ နယ်သာလန်မှာ Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 မှ။ အကြောင်းဖတ်ပါ။ Infrastructure Corp ကို ဘယ်လိုတည်ဆောက်မလဲ။ တစ်ပြားတစ်ချပ်အတွက် ယူရို ၉၀၀၀ တန် Dell R730xd E5-2650 v4 ဆာဗာများကို အသုံးပြုခြင်း။

source: www.habr.com