DEVOXX UK ထုတ်လုပ်မှုတွင် Kubernetes- အပြာ/အစိမ်း ဖြန့်ကျက်မှု၊ အလိုအလျောက် အတိုင်းအတာနှင့် အသုံးချမှု အလိုအလျောက် လုပ်ဆောင်မှု။ အပိုင်း 2

Kubernetes သည် အစုလိုက်အပြုံလိုက် ထုတ်လုပ်မှုပတ်ဝန်းကျင်တွင် Docker ကွန်တိန်နာများကို အသုံးပြုရန်အတွက် ကောင်းမွန်သောကိရိယာတစ်ခုဖြစ်သည်။ သို့သော် Kubernetes မဖြေရှင်းနိုင်သော ပြဿနာများရှိပါသည်။ မကြာခဏ ထုတ်လုပ်မှု ဖြန့်ကျက်ခြင်းအတွက်၊ ပြင်ပ HTTP တောင်းဆိုမှုများကို ကိုင်တွယ်ရန်နှင့် SSL offload များကို လုပ်ဆောင်ရန် လိုအပ်သည့် လုပ်ငန်းစဉ်တွင် စက်ရပ်ခြင်းကို ရှောင်ရှားရန် အပြည့်အဝ အလိုအလျောက် အပြာရောင်/အစိမ်းရောင် ဖြန့်ကျက်မှု လိုအပ်ပါသည်။ ၎င်းသည် ha-proxy ကဲ့သို့သော load balancer နှင့် ပေါင်းစည်းရန် လိုအပ်သည်။ နောက်ထပ်စိန်ခေါ်မှုမှာ cloud ပတ်ဝန်းကျင်တွင် လုပ်ဆောင်နေချိန်တွင် Kubernetes အစုအဝေးကို တစ်ဝက်တစ်ပျက် အလိုအလျောက် ချိန်ညှိခြင်း ဥပမာ၊ ညအချိန်တွင် အစုအဝေးကို တစ်စိတ်တစ်ပိုင်း ချဲ့ထွင်ခြင်း။

Kubernetes တွင် ဤအင်္ဂါရပ်များ မပါရှိသော်လည်း ၎င်းသည် အလားတူပြဿနာများကို ဖြေရှင်းရန်အတွက် သင်အသုံးပြုနိုင်သည့် API တစ်ခုကို ပေးပါသည်။ အပြာရောင်/စိမ်းလန်းသော အလိုအလျောက် ဖြန့်ကျက်ခြင်းနှင့် Kubernetes အစုအဝေးအတွက် ကိရိယာများကို ပွင့်လင်းမြင်သာစွာအခြေခံ၍ ဖန်တီးထားသည့် Cloud RTI ပရောဂျက်၏ တစ်စိတ်တစ်ပိုင်းအဖြစ် တီထွင်ခဲ့သည်။

ဗီဒီယိုမှတ်တမ်းတစ်ခုဖြစ်သည့် ဤဆောင်းပါးသည် ထုတ်လုပ်မှုတွင် အချိန်မဆိုင်းဘဲ git commit မှကုဒ်ကို လက်ခံသည့် ထုတ်လုပ်ရေးအဆင်သင့်ရှိသော ပတ်ဝန်းကျင်ကို ဖန်တီးရန်အတွက် Kubernetes ကို အခြား open source အစိတ်အပိုင်းများနှင့်အတူ မည်သို့ထည့်သွင်းရမည်ကို ပြသထားသည်။

DEVOXX UK ထုတ်လုပ်မှုတွင် Kubernetes- အပြာ/အစိမ်း ဖြန့်ကျက်မှု၊ အလိုအလျောက် အတိုင်းအတာနှင့် အသုံးချမှု အလိုအလျောက် လုပ်ဆောင်မှု။ အပိုင်း 1

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

Kubernetes သည် သေတ္တာအတွင်းမှ အကျိုးရှိရှိအသုံးပြုနိုင်သော ကိရိယာတစ်ခုမဟုတ်ပါ။ သေချာပါတယ်၊ သင်အဲဒါကိုလုပ်နိုင်တယ်၊ kubectl စသည်ဖြင့်သုံးပါ၊ ဒါပေမယ့် API ကဒီပလပ်ဖောင်းအတွက်စိတ်ဝင်စားစရာအကောင်းဆုံးနဲ့အသုံးဝင်ဆုံးအရာပါ။ လုပ်ဆောင်ချက်အစုတစ်ခုအနေဖြင့် API ကိုအသုံးပြုခြင်းဖြင့် Kubernetes တွင် သင်လုပ်ဆောင်လိုသည့် အရာအားလုံးနီးပါးကို သင်ဝင်ရောက်နိုင်သည်။ kubectl ကိုယ်တိုင်လည်း REST API ကိုအသုံးပြုသည်။

၎င်းသည် REST ဖြစ်သည်၊ ထို့ကြောင့် သင်သည် ဤ API နှင့် အလုပ်လုပ်ရန် မည်သည့်ဘာသာစကား သို့မဟုတ် ကိရိယာကိုမဆို သုံးနိုင်သော်လည်း စိတ်ကြိုက်စာကြည့်တိုက်များက သင့်ဘဝကို ပိုမိုလွယ်ကူစေမည်ဖြစ်သည်။ ကျွန်ုပ်၏အဖွဲ့သည် ထိုကဲ့သို့သော စာကြည့်တိုက် ၂ ခုကို ရေးသားခဲ့သည်- Java/OSGi အတွက် တစ်ခုနှင့် Go အတွက် တစ်ခု။ ဒုတိယတစ်မျိုးကို မကြာခဏအသုံးမပြုသော်လည်း မည်သည့်အခြေအနေမျိုးတွင်မဆို သင့်တွင် ဤအသုံးဝင်သောအရာများ ရှိနေပါသည်။ ၎င်းတို့သည် တစ်စိတ်တစ်ပိုင်း လိုင်စင်ရ open-source ပရောဂျက်တစ်ခုဖြစ်သည်။ ဘာသာစကားအမျိုးမျိုးအတွက် စာကြည့်တိုက်များစွာရှိသောကြောင့် သင်နှင့်အသင့်တော်ဆုံးများကို ရွေးချယ်နိုင်ပါသည်။

ထို့ကြောင့်၊ သင်၏ဖြန့်ကျက်မှုကို အလိုအလျောက်စတင်ခြင်းမပြုမီ၊ လုပ်ငန်းစဉ်သည် မည်သည့်အချိန်နှင့်မျှ ရပ်တန့်မည်မဟုတ်ကြောင်း သေချာစေရန်လိုအပ်ပါသည်။ ဥပမာအားဖြင့်၊ လူများသည် အပလီကေးရှင်းများကို အများဆုံးအသုံးပြုနေသည့် နေ့လယ်တွင် ကျွန်ုပ်တို့၏အဖွဲ့သည် ထုတ်လုပ်မှုကို ဖြန့်ကျက်လုပ်ဆောင်နေသောကြောင့် ဤလုပ်ငန်းစဉ်တွင် နှောင့်နှေးမှုများကို ရှောင်ရှားရန် အရေးကြီးပါသည်။ စက်ရပ်ခြင်းကို ရှောင်ရှားရန်အတွက် နည်းလမ်း 2 ခုကို အသုံးပြုသည်- အပြာ/အစိမ်း ဖြန့်ကျက်ခြင်း သို့မဟုတ် လှိမ့်မွမ်းမံခြင်း။ နောက်ဆုံးအခြေအနေတွင်၊ သင့်တွင် အပလီကေးရှင်းပုံတူ ၅ ခု လည်ပတ်နေပါက၊ ၎င်းတို့ကို တစ်ခုပြီးတစ်ခု အဆင့်မြှင့်ထားသည်။ ဤနည်းလမ်းသည် ကောင်းမွန်သော်လည်း အသုံးချမှုလုပ်ငန်းစဉ်အတွင်း သင့်တွင် အသုံးချပရိုဂရမ်၏ မတူညီသောဗားရှင်းများရှိပါက ၎င်းသည် မသင့်လျော်ပါ။ ဤကိစ္စတွင်၊ backend သည် ဗားရှင်းဟောင်းကို လုပ်ဆောင်နေချိန်တွင် အသုံးပြုသူ၏ အင်တာဖေ့စ်ကို သင် အပ်ဒိတ်လုပ်နိုင်ပြီး အပလီကေးရှင်း အလုပ်မလုပ်တော့ပါ။ ထို့ကြောင့်၊ ပရိုဂရမ်းမင်းရှုထောင့်အရ၊ ထိုသို့သောအခြေအနေများတွင် လုပ်ဆောင်ရန်မှာ အလွန်ခက်ခဲပါသည်။

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

အပြာ/အစိမ်း ဖြန့်ကျက်မှု ယန္တရားသည် ဤကဲ့သို့ ဖြစ်ပုံရသည်။ ကျွန်ုပ်တို့သည် ha-proxy မှတဆင့် ကျွန်ုပ်တို့၏အပလီကေးရှင်းများအတွက် အသွားအလာကို လက်ခံရရှိသည်၊ ၎င်းသည် တူညီသောဗားရှင်း၏ အပလီကေးရှင်း၏ပုံတူများကို လည်ပတ်နေပါသည်။

အသစ်ဖြန့်ကျက်မှုကို ပြုလုပ်သောအခါ၊ ကျွန်ုပ်တို့သည် အစိတ်အပိုင်းအသစ်များကို ပေးဆောင်ပြီး ဗားရှင်းအသစ်ကို ဖြန့်ကျက်ပေးသည့် Deployer ကို အသုံးပြုပါသည်။ အပလီကေးရှင်း၏ ဗားရှင်းအသစ်ကို ဖြန့်ကျက်ခြင်းသည် ပုံစံတူအစုအသစ်တစ်ခုကို "မြှင့်တင်သည်" ဟု ဆိုလိုသည်၊ ထို့နောက် ဤဗားရှင်းအသစ်၏ ပုံတူများကို သီးခြား pod အသစ်တစ်ခုတွင် စတင်လိုက်ပါသည်။ သို့ရာတွင်၊ ha-proxy သည် ၎င်းတို့အကြောင်း ဘာမှမသိရသေးဘဲ ၎င်းတို့ထံ မည်သည့်အလုပ်တာဝန်ကိုမျှ မပေးပို့ရသေးပါ။

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

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

အပ်ဒိတ်လုပ်ထားသောပုံတူများအားလုံးအလုပ်လုပ်နေကြောင်းစနစ်ကအတည်ပြုပြီးနောက်၊ Deployer သည်ဖွဲ့စည်းပုံကိုမွမ်းမံပြီး ha-proxy ကိုပြန်လည်စီစဉ်ပေးမည့်မှန်ကန်သော confd ကိုဖြတ်သန်းမည်ဖြစ်သည်။

၎င်းပြီးနောက်မှသာ ဗားရှင်းအသစ်၏ပုံတူများနှင့်အတူ pod သို့ အသွားအလာရှိလာမည်ဖြစ်ပြီး pod အဟောင်းသည် ပျောက်သွားမည်ဖြစ်သည်။

ဤယန္တရားသည် Kubernetes ၏အင်္ဂါရပ်မဟုတ်ပါ။ အပြာ/အစိမ်း ဖြန့်ကျက်ခြင်း၏ သဘောတရားမှာ အချိန်အတော်ကြာခဲ့ပြီဖြစ်ပြီး ၎င်းသည် Load Balancer ကို အမြဲအသုံးပြုခဲ့သည်။ ပထမဦးစွာ သင်သည် အပလီကေးရှင်း၏ ဗားရှင်းဟောင်းသို့ လမ်းကြောင်းအားလုံးကို ညွှန်ပြပြီး အပ်ဒိတ်ပြီးနောက်၊ သင်သည် ၎င်းကို ဗားရှင်းအသစ်သို့ အပြီးအပိုင် လွှဲပြောင်းပါ။ ဤမူကို Kubernetes တွင်သာမကဘဲ အသုံးပြုသည်။

ယခု ကျွန်ုပ်သည် သင့်အား ကျန်းမာရေးစစ်ဆေးမှုများလုပ်ဆောင်ပေးခြင်း၊ ပရောက်စီများကို ပြန်လည်စီစဉ်ပေးခြင်းစသည်ဖြင့် လုပ်ဆောင်ပေးသည့် Deployer အသစ်တစ်ခုနှင့် မိတ်ဆက်ပေးပါမည်။ ၎င်းသည် ပြင်ပကမ္ဘာနှင့် မသက်ဆိုင်ဘဲ Kubernetes အတွင်း၌ ရှိနေသော အယူအဆတစ်ခုဖြစ်သည်။ Open-source ကိရိယာများကို အသုံးပြု၍ သင်၏ကိုယ်ပိုင် Deployer အယူအဆကို သင်မည်ကဲ့သို့ ဖန်တီးနိုင်သည်ကို ကျွန်ုပ်ပြသပါမည်။

ထို့ကြောင့်၊ Deployer လုပ်သည့် ပထမဆုံးအရာမှာ Kubernetes API ကို အသုံးပြု၍ RC ကူးယူထိန်းချုပ်သည့်ကိရိယာကို ဖန်တီးခြင်းဖြစ်သည်။ ဤ API သည် နောက်ထပ် ဖြန့်ကျက်မှုအတွက် pods နှင့် ဝန်ဆောင်မှုများကို ဖန်တီးပေးသည်၊ ဆိုလိုသည်မှာ ၎င်းသည် ကျွန်ုပ်တို့၏ အပလီကေးရှင်းများအတွက် လုံးဝအသစ်သော အစုအဝေးတစ်ခုကို ဖန်တီးပေးပါသည်။ RC သည် ပုံတူများစတင်နေပြီဟု အခိုင်အမာယုံကြည်သည်နှင့်တပြိုင်နက် ၎င်းတို့၏လုပ်ဆောင်နိုင်စွမ်းအပေါ် ကျန်းမာရေးစစ်ဆေးမှုပြုလုပ်မည်ဖြစ်သည်။ ဒါကိုလုပ်ဖို့၊ Deployer က GET /health command ကိုသုံးပါတယ်။ ၎င်းသည် သင့်လျော်သော စကန်ဖတ်သည့် အစိတ်အပိုင်းများကို လုပ်ဆောင်ပြီး အစုအဝေး၏ လုပ်ဆောင်မှုကို ပံ့ပိုးပေးသည့် အစိတ်အပိုင်းအားလုံးကို စစ်ဆေးသည်။

pods များအားလုံးသည် ၎င်းတို့၏ကျန်းမာရေးကို အစီရင်ခံပြီးနောက်၊ Deployer သည် load balancer configuration ကို သိမ်းဆည်းခြင်းအပါအဝင် Kubernetes မှ အတွင်းပိုင်း၌ အသုံးပြုသည့် ခွဲဝေသိုလှောင်မှု- etcd ခွဲဝေသိုလှောင်မှုအသစ်တစ်ခုကို ဖန်တီးပေးပါသည်။ ကျွန်ုပ်တို့သည် ဒေတာကို etcd သို့ ရေးပြီး ဒေတာအသစ်အတွက် confd monitors etcd ဟုခေါ်သော ကိရိယာငယ်တစ်ခုဖြစ်သည်။

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

သင်တွေ့မြင်ရသည့်အတိုင်း၊ အစိတ်အပိုင်းများပေါများသော်လည်း၊ ဤနေရာတွင်ရှုပ်ထွေးသောအရာမရှိပါ။ API နဲ့ etcd ကို ပိုအာရုံစိုက်ဖို့ လိုပါတယ်။ ကျွန်ုပ်တို့ကိုယ်တိုင်အသုံးပြုနေသည့် အဖွင့်အရင်းအမြစ်ဖြန့်ကျက်သူအကြောင်း ပြောပြလိုသည်မှာ Amdatu Kubernetes Deployer။

၎င်းသည် Kubernetes ဖြန့်ကျက်မှုအား ကြိုးကိုင်ခြင်းအတွက် ကိရိယာတစ်ခုဖြစ်ပြီး အောက်ပါအင်္ဂါရပ်များပါရှိသည်။

• အပြာ/အစိမ်း ဖြန့်ကျက်ခြင်း၊
• ပြင်ပဝန်ချိန်ခွင်လျှာကို သတ်မှတ်ခြင်း၊
• ဖြန့်ကျက်ဖော်ပြရန် စီမံခန့်ခွဲမှု၊
• အမှန်တကယ် ဖြန့်ကျက်မှုကို စီမံခန့်ခွဲခြင်း၊
• ဖြန့်ကျက်စဉ်အတွင်း ကျန်းမာရေးစစ်ဆေးမှုများ၏ လုပ်ဆောင်နိုင်စွမ်းကို စစ်ဆေးခြင်း၊
• ပတ်ဝန်းကျင်ပြောင်းလဲမှုများကို pods များအဖြစ် အကောင်အထည်ဖော်ခြင်း။

ဤ Deployer သည် Kubernetes API ၏ထိပ်တွင် တည်ဆောက်ထားပြီး လက်ကိုင်များနှင့် ဖြန့်ကျက်မှုများကို စီမံခန့်ခွဲရန်အတွက် REST API နှင့် ဖြန့်ကျက်လုပ်ဆောင်နေစဉ်အတွင်း မှတ်တမ်းများကို တိုက်ရိုက်ကြည့်ရှုရန်အတွက် Websocket API ကို ပံ့ပိုးပေးပါသည်။

၎င်းသည် load balancer configuration data ကို etcd တွင် ထည့်သွင်းထားသောကြောင့် ha-proxy ကို out-of-the-box ပံ့ပိုးမှုဖြင့် အသုံးပြုရန် မလိုအပ်ဘဲ၊ သင်၏ကိုယ်ပိုင် load balancer configuration file ကို အလွယ်တကူ အသုံးပြုပါ။ Amdatu Deployer ကို Kubernetes ကိုယ်တိုင်ကဲ့သို့ Go တွင် ရေးသားထားပြီး Apache မှ လိုင်စင်ရထားသည်။

ဖြန့်ကျက်သူ၏ ဤဗားရှင်းကို အသုံးမပြုမီ၊ ကျွန်ုပ်လိုအပ်သော ဘောင်များကို သတ်မှတ်ပေးသည့် အောက်ပါ ဖြန့်ကျက်မှုဖော်ပြချက်ကို အသုံးပြုခဲ့သည်။

ဤကုဒ်၏ အရေးကြီးသော ကန့်သတ်ဘောင်များထဲမှတစ်ခုမှာ “useHealthCheck” အလံကို ဖွင့်ရန်ဖြစ်သည်။ ဖြန့်ကျက်ခြင်းလုပ်ငန်းစဉ်အတွင်း စိတ်ပိုင်းဆိုင်ရာ စစ်ဆေးမှုကို ပြုလုပ်ရမည်ဟု ကျွန်ုပ်တို့ သတ်မှတ်ရန် လိုအပ်ပါသည်။ ဖြန့်ကျက်မှုသည် အတည်ပြုရန်မလိုအပ်သော ပြင်ပအဖွဲ့အစည်းကွန်တိန်နာများကို အသုံးပြုသည့်အခါ ဤဆက်တင်ကို ပိတ်နိုင်သည်။ ဤဖော်ပြချက်သည် ha-proxy လိုအပ်သည့် ပုံတူအရေအတွက်နှင့် ရှေ့ဆုံး URL ကိုလည်း ဖော်ပြသည်။ အဆုံးတွင် port configuration၊ image စသည်တို့အတွက် အချက်အလက်အတွက် Kubernetes ကိုခေါ်ဆိုသည့် pod specification အလံ "podspec" ဖြစ်သည်။ ၎င်းသည် ရိုးရိုးရှင်းရှင်း JSON ဖော်ပြချက်ဖြစ်သည်။

open-source Amdatu ပရောဂျက်၏တစ်စိတ်တစ်ပိုင်းဖြစ်သော နောက်ထပ်ကိရိယာတစ်ခုမှာ Deploymentctl ဖြစ်သည်။ ၎င်းတွင် ဖြန့်ကျက်မှုများကို စီစဉ်သတ်မှတ်ရန်၊ ဖြန့်ကျက်မှုမှတ်တမ်းကို သိမ်းဆည်းရန်၊ ပြင်ပကုမ္ပဏီအသုံးပြုသူများနှင့် ဆော့ဖ်ဝဲရေးသားသူများထံမှ ပြန်လည်ခေါ်ယူမှုအတွက် ဝဘ်ချိတ်များပါရှိသည်။ Amdatu Deployer ကိုယ်တိုင်က REST API ဖြစ်သောကြောင့် UI ကို သင်အသုံးမပြုနိုင်သော်လည်း ဤအင်တာဖေ့စ်သည် မည်သည့် API မျှမပါဝင်ဘဲ သင့်အတွက် ပိုမိုလွယ်ကူစေနိုင်ပါသည်။ Deploymentctl ကို Angular 2 ကို အသုံးပြု၍ OSGi/Vertx ဖြင့် ရေးသားထားသည်။

စောင့်ဆိုင်းစရာမလိုဘဲ ကြိုတင်မှတ်တမ်းတင်ထားသော အသံဖိုင်ကို အသုံးပြု၍ အထက်ဖော်ပြပါ မြင်ကွင်းကို ယခု ကျွန်ုပ် သရုပ်ပြပါမည်။ ကျွန်ုပ်တို့သည် ရိုးရှင်းသော Go အပလီကေးရှင်းကို အသုံးပြုပါမည်။ Go ကိုအရင်မစမ်းရသေးရင် စိတ်မပူပါနဲ့၊ ဒါဟာ အရမ်းရိုးရှင်းတဲ့ application တစ်ခုဖြစ်လို့ သင်သိနိုင်သင့်ပါတယ်။

ဤတွင် ကျွန်ုပ်တို့သည် /health ကိုသာ တုံ့ပြန်သည့် HTTP ဆာဗာကို ဖန်တီးနေသည်၊ ထို့ကြောင့် ဤအပလီကေးရှင်းသည် ကျန်းမာရေးစစ်ဆေးမှုသာဖြစ်ပြီး အခြားဘာမျှမရှိပေ။ စစ်ဆေးမှုအောင်မြင်ပါက၊ အောက်တွင်ဖော်ပြထားသော JSON ဖွဲ့စည်းပုံကို အသုံးပြုသည်။ ၎င်းတွင် deployer မှ အသုံးချမည့် အပလီကေးရှင်းဗားရှင်း၊ ဖိုင်၏ထိပ်တွင် သင်မြင်ရသည့် မက်ဆေ့ချ်နှင့် ကျွန်ုပ်တို့၏ အပလီကေးရှင်းသည် အလုပ်မလုပ်သည်ဖြစ်စေ boolean ဒေတာအမျိုးအစား ပါရှိသည်။

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

ဒါဆို စလိုက်ရအောင်။ ပထမဦးစွာ၊ ကျွန်ုပ်တို့သည် command ~ kubectl get pods ကို အသုံးပြု၍ လုပ်ဆောင်နေသည့် မည်သည့် pods များ၏ရှေ့မှောက်တွင်မဆို စစ်ဆေးပြီး frontend URL မှ တုံ့ပြန်မှုမရှိခြင်းအပေါ် အခြေခံ၍၊ လက်ရှိတွင် ဖြန့်ကျက်မှုများ ပြုလုပ်ထားကြောင်း သေချာပါသည်။

နောက်တစ်ခုတွင် ကျွန်ုပ်ဖော်ပြခဲ့သော Deploymentctl အင်တာဖေ့စ်ကို သင်တွေ့မြင်ရပြီး၊ ဖြန့်ကျက်မှုဆိုင်ရာ ကန့်သတ်ချက်များသတ်မှတ်ထားသည်- namespace၊ အပလီကေးရှင်းအမည်၊ ဖြန့်ကျက်ဗားရှင်း၊ ပုံတူအရေအတွက်၊ ရှေ့ဆုံး URL၊ ကွန်တိန်နာအမည်၊ ရုပ်ပုံ၊ အရင်းအမြစ်ကန့်သတ်ချက်များ၊ ကျန်းမာရေးစစ်ဆေးမှုအတွက် ဆိပ်ကမ်းနံပါတ်၊ စသည်တို့။ ၎င်းတို့သည် သင့်အား ဖြစ်နိုင်ချေအများဆုံး ဟာ့ဒ်ဝဲပမာဏကို အသုံးပြုခွင့်ပေးသောကြောင့် အရင်းအမြစ်ကန့်သတ်ချက်များသည် အလွန်အရေးကြီးပါသည်။ ဤနေရာတွင် သင်သည် အသုံးချမှုမှတ်တမ်းကိုလည်း ကြည့်ရှုနိုင်သည်။

ယခု သင် ~ kubectl get pods ဟူသော အမိန့်ကို ပြန်လုပ်ပါက၊ ha-proxy ကို ပြန်လည်ပြင်ဆင်ထားသည့်အတောအတွင်း စနစ်သည် စက္ကန့် 20 ကြာ “အေးခဲ” သည်ကို တွေ့နိုင်သည်။ ထို့နောက်တွင်၊ ပေါ့ဒ်စတင်သည်နှင့် ကျွန်ုပ်တို့၏ပုံစံတူကို ဖြန့်ကျက်မှုမှတ်တမ်းတွင် တွေ့မြင်နိုင်ပါသည်။

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

အခု ဒုတိယဗားရှင်းကို စမ်းကြည့်ရအောင်။ ဒါကိုလုပ်ဖို့၊ "Hello, Kubernetes!" မှ အပလီကေးရှင်းရဲ့ မက်ဆေ့ချ်ကို ပြောင်းလိုက်တယ်။ “Hello, Deployer!” တွင်၊ စနစ်သည် ဤပုံအား ဖန်တီးပြီး ၎င်းကို Docker မှတ်ပုံတင်မှုတွင် နေရာချထားပြီးနောက်၊ ကျွန်ုပ်တို့သည် Deploymentctl ဝင်းဒိုးတွင် “Deploy” ခလုတ်ကို ထပ်မံနှိပ်လိုက်ပါသည်။ ဤကိစ္စတွင်၊ အပလီကေးရှင်း၏ပထမဗားရှင်းကို ဖြန့်ကျက်သောအခါတွင် အသုံးချမှုမှတ်တမ်းကို အလိုအလျောက်စတင်သည်။

command ~ kubectl get pods သည် လက်ရှိတွင် အပလီကေးရှင်း ဗားရှင်း 2 ခု လည်ပတ်နေကြောင်း ပြသသော်လည်း ရှေ့တန်းတွင် ကျွန်ုပ်တို့သည် ဗားရှင်း 1 ကို ဆက်လက် လုပ်ဆောင်နေသေးကြောင်း ပြသသည်။

load balancer သည် ဗားရှင်းအသစ်သို့ အသွားအလာကို ပြန်ညွှန်းခြင်းမပြုမီ ကျန်းမာရေးစစ်ဆေးမှု အပြီးသတ်ရန် စောင့်ဆိုင်းနေပါသည်။ စက္ကန့် 20 ကြာပြီးနောက်၊ ကျွန်ုပ်တို့သည် curl သို့ပြောင်းပြီး ယခုကျွန်ုပ်တို့၌ အပလီကေးရှင်း၏ ဗားရှင်း 2 ကို အသုံးပြုထားပြီး ပထမတစ်ခုကို ဖျက်လိုက်ပြီဖြစ်သည်။

ဤသည်မှာ "ကျန်းမာသော" အပလီကေးရှင်းတစ်ခု၏အသုံးချမှုဖြစ်သည်။ အပလီကေးရှင်း၏ ဗားရှင်းအသစ်အတွက် ကျွန်ုပ်သည် Healthy parameter ကို true မှ false သို့ ပြောင်းလဲမည်ဆိုပါက၊ ဆိုလိုသည်မှာ၊ ကျန်းမာရေးစစ်ဆေးမှု မအောင်မြင်သော အပလီကေးရှင်းတစ်ခုအား အသုံးပြုရန် ကြိုးစားကြည့်ကြပါစို့။ ဖွံ့ဖြိုးတိုးတက်မှုအဆင့်တွင် အပလီကေးရှင်းတွင် ဖွဲ့စည်းမှုပုံစံ အမှားအယွင်းအချို့ ပြုလုပ်ခဲ့ပြီး ၎င်းကို ဤပုံစံဖြင့် ထုတ်လုပ်ရေးသို့ ပေးပို့ပါက ၎င်းသည် ဖြစ်နိုင်သည်။

သင်မြင်ရသည့်အတိုင်း၊ ဖြန့်ကျက်မှုသည် အထက်ဖော်ပြပါအဆင့်များအားလုံးကို ဖြတ်သန်းပြီး ~kubectl get pods သည် pods နှစ်ခုလုံး အလုပ်လုပ်နေကြောင်း ပြသသည်။ သို့သော်ယခင်အသုံးပြုမှုနှင့်မတူဘဲ၊ မှတ်တမ်းသည် အချိန်ကုန်ဆုံးမှုအခြေအနေကိုပြသသည်။ ဆိုလိုသည်မှာ၊ ကျန်းမာရေးစစ်ဆေးမှုမအောင်မြင်သောကြောင့်၊ အပလီကေးရှင်း၏ဗားရှင်းအသစ်ကို အသုံးပြု၍မရပါ။ ရလဒ်အနေဖြင့်၊ စနစ်သည် အပလီကေးရှင်း၏ ဗားရှင်းဟောင်းကို အသုံးပြုခြင်းသို့ ပြန်လည်ရောက်ရှိသွားသည်ကို သင်တွေ့မြင်ရပြီး ဗားရှင်းအသစ်ကို ရိုးရိုးရှင်းရှင်းပင် ဖြုတ်ပစ်လိုက်ပါသည်။

၎င်းနှင့်ပတ်သက်သော ကောင်းသောအချက်မှာ သင့်တွင် အပလီကေးရှင်းသို့ တစ်ပြိုင်နက်တည်း တောင်းဆိုမှုများ အများအပြား ရောက်ရှိလာသော်လည်း၊ ဖြန့်ကျက်မှုလုပ်ငန်းစဉ်ကို အကောင်အထည်ဖော်စဉ်တွင် ၎င်းတို့သည် ရပ်နားချိန်ကိုပင် သတိမပြုမိဘဲ ဖြစ်နေခြင်းဖြစ်သည်။ တောင်းဆိုချက်များစွာကို တတ်နိုင်သမျှ ပေးပို့ပေးသော Gatling framework ကို အသုံးပြု၍ ဤအက်ပ်အား စမ်းသပ်ပါက၊ ယင်းတောင်းဆိုချက်များထဲမှ တစ်ခုမျှ ရုပ်သိမ်းမည်မဟုတ်ပါ။ ဆိုလိုသည်မှာ ကျွန်ုပ်တို့၏အသုံးပြုသူများသည် အချိန်နှင့်တပြေးညီ ဗားရှင်းအပ်ဒိတ်များကိုပင် သတိမထားမိနိုင်ပါ။ အဆင်မပြေပါက၊ ဗားရှင်းဟောင်းတွင် အလုပ်ဆက်လုပ်သွားမည်ဖြစ်ပြီး အောင်မြင်ပါက၊ အသုံးပြုသူများသည် ဗားရှင်းအသစ်သို့ ပြောင်းသွားမည်ဖြစ်သည်။

ကျရှုံးနိုင်သည့်အရာတစ်ခုသာရှိသည် - ကျန်းမာရေးစစ်ဆေးမှုအောင်မြင်ပါက၊ သို့သော် ၎င်းနှင့်သက်ဆိုင်သည့်အလုပ်တာဝန်ကို ထမ်းဆောင်သည်နှင့်တပြိုင်နက် လျှောက်လွှာပျက်သွားသည်၊ ဆိုလိုသည်မှာ၊ ဖြန့်ကျက်ပြီးမှသာ ပြိုကျမှုဖြစ်လိမ့်မည်။ ဤကိစ္စတွင်၊ သင်သည် ဗားရှင်းဟောင်းသို့ ကိုယ်တိုင်ပြန်လှည့်ရပါမည်။ ထို့ကြောင့်၊ ၎င်းအတွက်ဒီဇိုင်းထုတ်ထားသော open-source tools ဖြင့် Kubernetes ကိုမည်သို့အသုံးပြုရမည်ကို ကျွန်ုပ်တို့ကြည့်ရှုခဲ့သည်။ သင်၏ Build/Deploy pipelines တွင် ဤကိရိယာများကို သင်တည်ဆောက်ပါက အသုံးချမှုလုပ်ငန်းစဉ်သည် ပိုမိုလွယ်ကူလာမည်ဖြစ်သည်။ တစ်ချိန်တည်းမှာပင်၊ ဖြန့်ကျက်မှုစတင်ရန် သင်သည် အသုံးပြုသူအင်တာဖေ့စ်ကိုသုံးနိုင်သည် သို့မဟုတ် ဥပမာအားဖြင့် commit to master ကိုအသုံးပြုခြင်းဖြင့် ဤလုပ်ငန်းစဉ်ကို အပြည့်အဝအလိုအလျောက်လုပ်ဆောင်နိုင်သည်။

ကျွန်ုပ်တို့၏ Build Server သည် Docker ပုံတစ်ခုကို ဖန်တီးပြီး ၎င်းကို Docker Hub သို့ တွန်းပို့မည် သို့မဟုတ် သင်အသုံးပြုသည့် မည်သည့် registry ကိုမဆို ပြုလုပ်မည်ဖြစ်သည်။ Docker Hub သည် webhook ကို ပံ့ပိုးပေးသောကြောင့် အထက်တွင်ပြထားသည့်အတိုင်း Deployer မှတစ်ဆင့် အဝေးထိန်းစနစ်ဖြင့် ဖြန့်ကျက်မှုကို စတင်နိုင်ပါသည်။ ဤနည်းဖြင့် သင်သည် သင့်အပလီကေးရှင်း၏ ဖြန့်ကျက်မှုကို အလားအလာရှိသော ထုတ်လုပ်မှုတွင် အပြည့်အဝ အလိုအလျောက်လုပ်ဆောင်နိုင်သည်။

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

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

ကျွန်ုပ်တို့သည် Amazon သို့မဟုတ် အခြားသော cloud ဝန်ဆောင်မှုကို အသုံးပြုသည်ဖြစ်စေ Kubernetes သည် အသုံးပြုနေသည့် စက်အရေအတွက်နှင့်ပတ်သက်၍ ဘာမျှမသိသောကြောင့် ၎င်းသည် စိန်ခေါ်မှုဖြစ်နိုင်သည်။ ၎င်းသည် သင့်အား node အဆင့်တွင် စနစ်အား အတိုင်းအတာဖြင့် တိုင်းတာရန် ခွင့်ပြုသည့်ကိရိယာတစ်ခု ချို့တဲ့နေသည်။

ထို့ကြောင့် ကျွန်ုပ်တို့သည် node နှင့် pods တို့ကို ဂရုစိုက်ရမည်ဖြစ်ပါသည်။ Kubernetes လုပ်သား node အရေအတွက်ကို စီစဉ်သတ်မှတ်ရန် AWS API နှင့် Scaling အုပ်စုစက်များကို အသုံးပြု၍ node အသစ်များ၏ စတင်မှုကို အလွယ်တကူ အတိုင်းအတာဖြင့် တိုင်းတာနိုင်သည်။ Kubernetes အစုအဝေးတွင် node များကို စာရင်းသွင်းရန် cloud-init သို့မဟုတ် အလားတူ script ကို သင်အသုံးပြုနိုင်သည်။

စက်အသစ်သည် Scaling group တွင်စတင်သည်၊ node တစ်ခုအနေဖြင့်စတင်သည်၊ master's registry တွင်စာရင်းသွင်းပြီးအလုပ်လုပ်သည်။ ယင်းနောက်တွင်၊ ရလဒ်ထွက်ပေါ်နေသော node များတွင် အသုံးပြုရန်အတွက် ပုံတူအရေအတွက်ကို တိုးမြှင့်နိုင်သည်။ "မလိုအပ်သော" စက်များကိုပိတ်ပြီးနောက် ထိုသို့သောအဆင့်သည် လုပ်ဆောင်နေပြီးဖြစ်သော အပလီကေးရှင်းများ ပျက်စီးခြင်းသို့မရောက်ကြောင်း သေချာစေရန်အတွက် အရွယ်အစားကို လျှော့ချရန် လိုအပ်ပါသည်။ ထိုသို့သောအခြေအနေမျိုးမဖြစ်အောင်၊ သင်သည် node အား "အချိန်ဇယားဆွဲ၍မရသော" အခြေအနေသို့ သတ်မှတ်ရန်လိုအပ်သည်။ ဆိုလိုသည်မှာ DaemonSet pods များကို အချိန်ဇယားဆွဲသည့်အခါ မူရင်းအချိန်ဇယားဆွဲသူသည် ဤဆုံမှတ်များကို လျစ်လျူရှုလိမ့်မည်ဖြစ်သည်။ အစီအစဉ်ဆွဲသူသည် ဤဆာဗာများမှ မည်သည့်အရာကိုမျှ ဖျက်မည်မဟုတ်သော်လည်း ထိုနေရာတွင် ကွန်တိန်နာအသစ်များကိုလည်း ဖွင့်ပေးမည်မဟုတ်ပါ။ နောက်တစ်ဆင့်မှာ ၎င်းအတွက် လုံလောက်သော စွမ်းရည်ရှိသည့် အခြားစက်တစ်ခုသို့ လည်ပတ်နေသော pods များကို ၎င်းမှ လွှဲပြောင်းရန် နောက်တစ်ဆင့်မှာ drain node ကို ဖယ်ရှားရန်ဖြစ်သည်။ ဤ node များတွင် ကွန်တိန်နာများ မရှိတော့ကြောင်း သေချာပြီးသည်နှင့် ၎င်းတို့ကို Kubernetes မှ ဖယ်ရှားနိုင်ပါသည်။ ယင်းနောက်၊ ၎င်းတို့သည် Kubernetes အတွက် ရိုးရှင်းစွာ တည်ရှိတော့မည်ဖြစ်သည်။ ထို့နောက်၊ မလိုအပ်သော node သို့မဟုတ် စက်များကိုပိတ်ရန် AWS API ကိုအသုံးပြုရန်လိုအပ်သည်။
AWS API နဲ့ ဆင်တူတဲ့ အခြား open-source scaling tool ဖြစ်တဲ့ Amdatu Scalerd ကို သုံးနိုင်ပါတယ်။ ၎င်းသည် အစုအဝေးတစ်ခုတွင် node များထည့်ရန် သို့မဟုတ် ဖယ်ရှားရန် CLI ကို ပံ့ပိုးပေးသည်။ ၎င်း၏စိတ်ဝင်စားစရာကောင်းသောအင်္ဂါရပ်မှာ အောက်ပါ json ဖိုင်ကိုအသုံးပြု၍ အချိန်ဇယားဆွဲခြင်းကို ချိန်ညှိနိုင်မှုဖြစ်သည်။

ပြထားသည့်ကုဒ်သည် ညအချိန်ကာလအတွင်း အစုအဝေး၏စွမ်းရည်ကို ထက်ဝက်လျှော့ချပေးသည်။ ၎င်းသည် ရရှိနိုင်သော ပုံတူအရေအတွက်နှင့် Amazon အစုအဝေး၏ အလိုရှိသော စွမ်းရည်နှစ်မျိုးလုံးကို စီစဉ်ပေးသည်။ ဤအချိန်ဇယားကို အသုံးပြုခြင်းဖြင့် ညအချိန်တွင် node အရေအတွက်ကို အလိုအလျောက်လျှော့ချပြီး နံနက်ပိုင်းတွင် ၎င်းတို့ကို တိုးစေပြီး Amazon ကဲ့သို့ cloud ဝန်ဆောင်မှုမှ node များကို အသုံးပြုခြင်းကုန်ကျစရိတ်ကို သက်သာစေပါသည်။ ဤအင်္ဂါရပ်သည် Kubernetes တွင်တည်ဆောက်ထားခြင်းမဟုတ်သော်လည်း Scalerd ကိုအသုံးပြုခြင်းဖြင့် သင်သည် ဤပလပ်ဖောင်းကို သင်အလိုရှိသည့်အတိုင်း စကေးချနိုင်စေမည်ဖြစ်သည်။

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

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

ခေါင်းစဉ်ကိုနိဂုံးချုပ်ရန်၊ ကျွန်ုပ်၏အဖွဲ့လုပ်ဆောင်နေသည့် Kubernetes ကိုအခြေခံသည့် Cloud RTI ပလပ်ဖောင်းနှင့် မိတ်ဆက်ပေးလိုပါသည်။ ၎င်းသည် ဗဟိုချုပ်ကိုင်မှုရှိသော မှတ်တမ်းရယူခြင်း၊ အပလီကေးရှင်းနှင့် အစုလိုက်စောင့်ကြည့်ခြင်း နှင့် အသုံးဝင်လာမည့် အခြားအသုံးဝင်သော အင်္ဂါရပ်များစွာကို ပံ့ပိုးပေးပါသည်။ စောင့်ကြည့်မှုကိုပြသရန် Grafana ကဲ့သို့သော open-source tools အမျိုးမျိုးကိုအသုံးပြုသည်။

Kubernetes နှင့် ha-proxy load balancer ကို အဘယ်ကြောင့် အသုံးပြုရသနည်းဟု မေးစရာရှိလာသည်။ လက်ရှိတွင် ဝန်ချိန်ခွင်လျှာ အဆင့် 2 ဆင့်ရှိသောကြောင့် မေးခွန်းကောင်းဖြစ်သည်။ Kubernetes ဝန်ဆောင်မှုများသည် virtual IP လိပ်စာများပေါ်တွင် ဆက်လက်တည်ရှိဆဲဖြစ်သည်။ Amazon သည် ၎င်း၏ cloud host ကို overload လုပ်ပါက လိပ်စာပြောင်းမည်ဖြစ်သောကြောင့် ၎င်းတို့ကို ပြင်ပ host စက်များရှိ port များအတွက် သင်အသုံးမပြုနိုင်ပါ။ ထို့ကြောင့် ကျွန်ုပ်တို့သည် Kubernetes နှင့် ချောမွေ့စွာ ဆက်သွယ်နိုင်ရန် အသွားအလာအတွက် ပိုမိုတည်ငြိမ်သော ဖွဲ့စည်းပုံကို ဖန်တီးရန် ဝန်ဆောင်မှုများရှေ့တွင် ha-proxy ကို နေရာချထားသည်။

နောက်ထပ်မေးခွန်းကောင်းတစ်ခုကတော့ အပြာ/အစိမ်း ဖြန့်ကျက်မှုလုပ်တဲ့အခါ ဒေတာဘေ့စ်စကမာပြောင်းလဲမှုတွေကို ဘယ်လိုဂရုစိုက်နိုင်မလဲ။ အမှန်မှာ Kubernetes ကို အသုံးပြုခြင်း ၊ database schema ကို ပြောင်းလဲခြင်းသည် ခက်ခဲသော အလုပ်ဖြစ်သည် ။ ထို့နောက် ဒေတာဘေ့စ်ကို အပ်ဒိတ်လုပ်ပြီး အပလီကေးရှင်းများကို ကိုယ်တိုင်မွမ်းမံပြင်ဆင်ပြီးနောက် အဟောင်းနှင့်အသစ် schema သည် သဟဇာတဖြစ်ရန် သေချာရန် လိုအပ်သည်။ ဒေတာဘေ့စ်ကို ပူပူနွေးနွေး လဲလှယ်ပြီးနောက် အပလီကေးရှင်းများကို အပ်ဒိတ်လုပ်နိုင်သည်။ schema အသစ်ဖြင့် လုံးဝအသစ်ဒေတာဘေ့စ်အစုအဝေးကို စတင်အသုံးပြုသူများအကြောင်း ကျွန်ုပ်သိပါသည်၊ အကယ်၍ သင့်တွင် Mongo ကဲ့သို့ အစီအစဥ်မရှိသောဒေတာဘေ့စ်တစ်ခုရှိလျှင် ၎င်းသည် ရွေးချယ်မှုတစ်ခုဖြစ်သည်၊ သို့သော် မည်သို့ပင်ဖြစ်စေ လွယ်ကူသောအလုပ်မဟုတ်ပါ။ သင့်တွင် နောက်ထပ်မေးခွန်းများမရှိပါက၊ သင်၏အာရုံစိုက်မှုအတွက် ကျေးဇူးတင်ပါသည်။

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

ကျွန်ုပ်တို့နှင့်အတူရှိနေသည့်အတွက် ကျေးဇူးတင်ပါသည်။ ကျွန်ုပ်တို့၏ဆောင်းပါးများကို သင်နှစ်သက်ပါသလား။ ပိုစိတ်ဝင်စားစရာကောင်းတဲ့ အကြောင်းအရာတွေကို ကြည့်ချင်ပါသလား။ မှာယူမှုတစ်ခုပြုလုပ်ခြင်း သို့မဟုတ် သူငယ်ချင်းများကို အကြံပြုခြင်းဖြင့် ကျွန်ုပ်တို့အား ပံ့ပိုးကူညီပါ၊ $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