Kubernetes- ပွင့်လင်းရင်းမြစ်နှင့် ရောင်းချသူ-သီးသန့်

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

သူကပြောတယ် ဘာလဲ။ Kubernetes. ဤသည်မှာ host အများအပြားရှိကွန်တိန်နာများကိုစီမံခန့်ခွဲရန်စနစ်ဖြစ်သည်။ ဂရိဘာသာစကားအားဖြင့်၊ ၎င်းကို "လေယာဉ်မှူး" သို့မဟုတ် "ပဲ့နင်း" ဟုပြန်ဆိုသည်။ မူလက Google မှ တီထွင်ခဲ့ပြီး ကမ္ဘာ့ထိပ်တန်း developer များ၊ end users များနှင့် container technology providers များကို စုစည်းထားသည့် နိုင်ငံတကာ အကျိုးအမြတ်မယူသော အဖွဲ့အစည်းဖြစ်သည့် Cloud Native Computing Foundation သို့ နည်းပညာပံ့ပိုးမှုအနေဖြင့် လှူဒါန်းခဲ့ပါသည်။

ကွန်တိန်နာအများအပြားကို စီမံခန့်ခွဲပါ။

ကဲ ဘယ်လို ကွန်တိန်နာ အမျိုးအစားတွေလဲ ဆိုတာ ကြည့်လိုက်ရအောင်။ ၎င်းသည် ၎င်း၏ပတ်ဝန်းကျင်တစ်ခုလုံးပါရှိသော အက်ပလီကေးရှင်းတစ်ခုဖြစ်သည်။ အဓိကအားဖြင့် ပရိုဂရမ်အပေါ် မူတည်သည့် စာကြည့်တိုက်များဖြစ်သည်။ ဤအရာအားလုံးကို မော်ကွန်းတိုက်တွင် ထုပ်ပိုးထားပြီး လည်ပတ်မှုစနစ် မည်သို့ပင်ရှိစေကာမူ စမ်းသပ်ပြီး အခြားအရာများကို လုပ်ဆောင်နိုင်သည့် ရုပ်ပုံတစ်ခုအသွင်ဖြင့် တင်ပြထားသည်။ ဒါပေမယ့် ပြဿနာတစ်ခုရှိတယ် - hosts အများအပြားမှာ containers တွေကို စီမံခန့်ခွဲရတာ အရမ်းခက်ခဲပါတယ်။ ထို့ကြောင့် Kubernetes ကို ဖန်တီးခဲ့သည်။

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

ကျွန်ုပ်တို့သည် ကွန်တိန်နာတစ်ခုမှ အက်ပလီကေးရှင်းတစ်ခုကို လည်ပတ်လိုသောအခါတွင် လိုအပ်သော အလွှာများကို တစ်ခုနှင့်တစ်ခု ပေါင်းစပ်ကာ overlay ဖိုင်စနစ်တစ်ခုကို ဖွဲ့စည်းထားသည်။ ကွန်တိန်နာရပ်သွားသည့်အခါ ဖယ်ရှားမည့် အသံဖမ်းအလွှာကို အပေါ်ဆုံးတွင် ထားရှိပါ။ ၎င်းသည် ကွန်တိန်နာလည်ပတ်သည့်အခါ၊ အပလီကေးရှင်းတွင် ပြောင်းလဲ၍မရသော တူညီသောပတ်ဝန်းကျင် အမြဲရှိနေမည်ဖြစ်ကြောင်း သေချာစေသည်။ ၎င်းသည် မတူညီသော host OS များတွင် ပတ်၀န်းကျင်၏ ပြန်လည်ထုတ်လုပ်နိုင်မှုကို အာမခံပါသည်။ Ubuntu သို့မဟုတ် CentOS ပဲဖြစ်ဖြစ်၊ ပတ်ဝန်းကျင်က အမြဲတမ်း အတူတူပါပဲ။ ထို့အပြင်၊ ကွန်တိန်နာအား Linux kernel တွင်တည်ဆောက်ထားသော ယန္တရားများကို အသုံးပြု၍ ကွန်တိန်နာကို host နှင့် သီးခြားခွဲထားသည်။ ကွန်တိန်နာတစ်ခုရှိ အပလီကေးရှင်းများသည် ဖိုင်များ၊ လက်ခံဆောင်ရွက်ပေးသည့် ကွန်တိန်နာများနှင့် အနီးနားရှိ ကွန်တိန်နာများ၏ လုပ်ငန်းစဉ်များကို မမြင်ရပါ။ ဤ host OS မှ အပလီကေးရှင်းများကို သီးခြားခွဲထားခြင်းဖြင့် နောက်ထပ် လုံခြုံရေးအလွှာကို ပံ့ပိုးပေးပါသည်။

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

Kubernetes အတွက် ဝယ်လိုအားသည် တစ်ခုတည်းသော အရာတစ်မျိုးအဖြစ် host များစွာရှိ ကွန်တိန်နာအုပ်စုများကို စီမံခန့်ခွဲနိုင်ခြင်းကြောင့် အတိအကျဖြစ်သည်။ စနစ်၏လူကြိုက်များမှုသည် DevOps သို့မဟုတ် Development Operations ကိုတည်ဆောက်ရန် အခွင့်အလမ်းပေးသည်၊ ၎င်းတွင် Kubernetes ကို ဤ DevOps ၏လုပ်ငန်းစဉ်များကိုလုပ်ဆောင်ရန်အသုံးပြုသည်။

ပုံ 1. Kubernetes အလုပ်လုပ်ပုံ ဇယားကွက်ကို ကိုယ်စားပြုခြင်း။

အလိုအလျောက်စနစ် အပြည့်

DevOps သည် အခြေခံအားဖြင့် ဖွံ့ဖြိုးတိုးတက်မှုလုပ်ငန်းစဉ်၏ အလိုအလျောက်လုပ်ဆောင်မှုဖြစ်သည်။ အကြမ်းဖျင်းအားဖြင့်ပြောရလျှင် developer များသည် repository သို့အပ်လုဒ်တင်ထားသောကုဒ်ကိုရေးကြသည်။ ထို့နောက် ဤကုဒ်ကို စာကြည့်တိုက်များ အားလုံးပါရှိသော ကွန်တိန်နာတစ်ခုထဲသို့ ချက်ခြင်း အလိုအလျောက် စုဆောင်းနိုင်သည်၊ စမ်းသပ်ပြီး နောက်တစ်ဆင့်သို့ "ထုတ်သည်" - Staging၊ ထို့နောက် ချက်ချင်း ထုတ်လုပ်ရေးသို့ ရောက်ရှိသွားပါသည်။

Kubernetes နှင့်အတူ၊ DevOps သည် သင့်အား developer များကိုယ်တိုင်ပါဝင်မှု မရှိသလောက်နည်းဖြင့် ဤလုပ်ငန်းစဉ်ကို အလိုအလျောက်လုပ်ဆောင်နိုင်စေပါသည်။ ထို့အတွက်ကြောင့် developer သည် ၎င်း၏ကွန်ပြူတာတွင် ၎င်းကိုလုပ်ဆောင်ရန်မလိုအပ်သောကြောင့် builder သည် သိသိသာသာမြန်ဆန်လာသည် - သူသည် ကုဒ်တစ်ပိုင်းကို ရိုးရိုးရှင်းရှင်းရေးပြီး ကုဒ်ကို repository သို့တွန်းပို့ကာ၊ ပိုက်လိုင်းကို စတင်လိုက်ပြီးနောက်၊ လုပ်ငန်းစဉ်တွင် ပါဝင်နိုင်သည့်၊ ဆောက်လုပ်ခြင်း၊ စမ်းသပ်ခြင်းနှင့် ထုတ်ခြင်း ပြီးတော့ ဒါက ကတိကဝတ်တိုင်းနဲ့ ဖြစ်တတ်တာမို့ စမ်းသပ်မှုဟာ စဉ်ဆက်မပြတ် ဖြစ်ပေါ်နေပါတယ်။

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

Pros, pros, pros

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

• ပုံတူများစွာကို စီမံခန့်ခွဲခြင်း။ အရေးကြီးဆုံးအချက်မှာ host အများအပြားရှိ containers များကို စီမံခန့်ခွဲခြင်းဖြစ်သည်။ ပို၍အရေးကြီးသည်မှာ၊ ကွန်တိန်နာအတွင်း အပလီကေးရှင်းပုံတူများကို တစ်ခုတည်းသော အဖွဲ့အစည်းအဖြစ် စီမံခန့်ခွဲပါ။ ယင်းကြောင့် အင်ဂျင်နီယာများသည် ကွန်တိန်နာတစ်ခုစီအတွက် စိတ်ပူစရာမလိုပါ။ ကွန်တိန်နာများထဲမှ တစ်ခုပျက်သွားပါက Kubernetes သည် ၎င်းကိုမြင်ရပြီး ၎င်းကို ပြန်လည်စတင်ပါမည်။
• အစုအဖွဲ့ကွန်ရက်။ Kubernetes တွင် ၎င်း၏ကိုယ်ပိုင်လိပ်စာနေရာနှင့်အတူ အစုအဖွဲ့ဟုခေါ်သော ကွန်ရက်တစ်ခုလည်း ရှိသည်။ ဤအတွက်ကြောင့် pod တစ်ခုချင်းစီတွင်၎င်း၏လိပ်စာရှိသည်။ ကွန်တိန်နာများကို တိုက်ရိုက်ထုတ်လွှတ်သည့် အစုအဝေးတစ်ခု၏ အနိမ့်ဆုံးဖွဲ့စည်းပုံဆိုင်ရာ ယူနစ်အဖြစ် subpod ကို နားလည်သည်။ ထို့အပြင်၊ Kubernetes တွင် load balancer နှင့် Service Discovery တို့ကို ပေါင်းစပ်ထားသည့် လုပ်ဆောင်နိုင်စွမ်း ရှိပါသည်။ ၎င်းသည် သင်ကိုယ်တိုင် IP လိပ်စာစီမံခန့်ခွဲမှုကို ဖယ်ရှားပြီး ဤတာဝန်ကို Kubernetes သို့ လွှဲအပ်ခွင့်ပြုသည်။ ထို့အပြင် အလိုအလျောက် ကျန်းမာရေးစစ်ဆေးမှုများသည် ပြဿနာများကို ရှာဖွေတွေ့ရှိနိုင်ပြီး အလုပ်လုပ်သော pods များသို့ လမ်းကြောင်းပြောင်းရန် ကူညီပေးပါမည်။
• ဖွဲ့စည်းမှုစီမံခန့်ခွဲမှု။ အပလီကေးရှင်းအများအပြားကို စီမံခန့်ခွဲသည့်အခါ၊ အက်ပ်ဖွဲ့စည်းပုံဖွဲ့စည်းပုံကို စီမံခန့်ခွဲရန် ခက်ခဲလာသည်။ ဤရည်ရွယ်ချက်အတွက်၊ Kubernetes တွင် အထူး ConfigMap အရင်းအမြစ်များရှိသည်။ ၎င်းတို့သည် သင့်အား အစီအစဥ်များကို အလယ်ဗဟိုတွင် သိမ်းဆည်းနိုင်ပြီး အပလီကေးရှင်းများလည်ပတ်သောအခါတွင် ၎င်းတို့အား pods များသို့ ဖော်ထုတ်ခွင့်ပြုသည်။ ဤယန္တရားသည် အနည်းဆုံး အပလီကေးရှင်း ဆယ်ခု သို့မဟုတ် တစ်ရာအတွင်း ဖွဲ့စည်းမှုပုံစံ၏ ညီညွတ်မှုကို အာမခံနိုင်စေပါသည်။
• အမြဲတမ်း အတွဲများ။ ကွန်တိန်နာများသည် မူရင်းအတိုင်း မပြောင်းလဲနိုင်ဘဲ ကွန်တိန်နာကို ရပ်လိုက်သောအခါ၊ ဖိုင်စနစ်သို့ ရေးထားသော ဒေတာအားလုံးကို ဖျက်ဆီးပစ်မည်ဖြစ်သည်။ သို့သော် အချို့သော အပလီကေးရှင်းများသည် ဒေတာကို ဒစ်ခ်ပေါ်တွင် တိုက်ရိုက်သိမ်းဆည်းသည်။ ဤပြဿနာကိုဖြေရှင်းရန်၊ Kubernetes တွင် ဒစ်ခ်သိုလှောင်မှုစီမံခန့်ခွဲမှုလုပ်ဆောင်ချက်- Persistent Volumes ရှိသည်။ ဤယန္တရားသည် ဒေတာအတွက် ပြင်ပသိုလှောင်မှုကို အသုံးပြုပြီး ဆက်တိုက်သိုလှောင်မှု၊ ပိတ်ဆို့ခြင်း သို့မဟုတ် ဖိုင်ကို ကွန်တိန်နာများအတွင်းသို့ လွှဲပြောင်းနိုင်သည်။ ဤဖြေရှင်းချက်သည် သင့်အား အလုပ်သမားများထံမှ ဒေတာများကို သီးခြားစီသိမ်းဆည်းနိုင်စေကာ ၎င်းတို့ကို တူညီသောအလုပ်သမားများ ပြိုကွဲပါက ၎င်းတို့ကို ကယ်တင်နိုင်မည်ဖြစ်သည်။
• Load Balancer Kubernetes တွင် ကျွန်ုပ်တို့သည် Deployment၊ StatefulSet စသည်တို့ကဲ့သို့ abstract entities များကို စီမံခန့်ခွဲသော်လည်း၊ နောက်ဆုံးတွင် containers များသည် ပုံမှန် virtual machines သို့မဟုတ် hardware servers များတွင် run ပါသည်။ ၎င်းတို့သည် မပြည့်စုံဘဲ အချိန်မရွေး လဲကျနိုင်သည်။ Kubernetes သည် ၎င်းကိုမြင်ရပြီး အတွင်းပိုင်းအသွားအလာကို အခြားပုံစံတူများထံ ပြန်ညွှန်းပါမည်။ ဒါပေမယ့် အပြင်ကလာတဲ့ ယာဉ်ကြောပိတ်ဆို့မှုနဲ့ ဘာလုပ်ရမလဲ။ အကယ်၍ သင်သည် အလုပ်သမားများထဲမှ တစ်ဦးကို လမ်းကြောင်းမှန်အတိုင်း ညွှန်ပြပါက၊ ပျက်စီးသွားပါက ဝန်ဆောင်မှု မရနိုင်တော့ပါ။ ဤပြဿနာကိုဖြေရှင်းရန်အတွက် Kubernetes တွင် Load Balancer ကဲ့သို့သော ဝန်ဆောင်မှုများရှိသည်။ ၎င်းတို့သည် အစုအဝေးရှိ အလုပ်သမားအားလုံးအတွက် ပြင်ပ cloud balancer ကို အလိုအလျောက် စီစဉ်သတ်မှတ်ရန် ဒီဇိုင်းထုတ်ထားသည်။ ဤပြင်ပ ချိန်ခွင်လျှာသည် အလုပ်သမားများထံ ပြင်ပအသွားအလာကို ညွှန်ကြားပြီး ၎င်းတို့၏ အခြေအနေကို ကိုယ်တိုင် စောင့်ကြည့်သည်။ တစ်ခု သို့မဟုတ် တစ်ခုထက်ပိုသော အလုပ်သမားများ မရရှိနိုင်ပါက ယာဉ်ကြောအသွားအလာကို အခြားသူများထံ ပြန်ညွှန်းပါသည်။ ၎င်းက Kubernetes ကို အသုံးပြု၍ အလွန်ရရှိနိုင်သော ဝန်ဆောင်မှုများကို ဖန်တီးနိုင်စေပါသည်။

မိုက်ခရိုဝန်ဆောင်မှု ဗိသုကာများကို လုပ်ဆောင်သောအခါ Kubernetes သည် အကောင်းဆုံးအလုပ်လုပ်သည်။ စနစ်ကို ဂန္တဝင်ဗိသုကာအဖြစ်သို့ အကောင်အထည်ဖော်ရန် ဖြစ်နိုင်သော်လည်း ၎င်းသည် အဓိပ္ပါယ်မရှိပေ။ အပလီကေးရှင်းတစ်ခုသည် ပုံစံတူများစွာကို မလည်ပတ်နိုင်ပါက Kubernetes တွင် ၎င်းသည် အဘယ်ကွာခြားချက်ဖြစ်စေနိုင်သည်ဖြစ်စေ မရှိသည်ဖြစ်စေ။

ပွင့်လင်းအရင်းအမြစ် Kubernetes

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

• ပထမအချက်မှာ ဤအရာအားလုံးကို အသုံးချပြီး ပံ့ပိုးပေးမည့် စီမံခန့်ခွဲသူများနှင့် အင်ဂျင်နီယာများ၏ အသိပညာနှင့် အတွေ့အကြုံများအတွက် လိုအပ်ချက်ဖြစ်သည်။ ကလိုင်းယင့်သည် အစုအဖွဲ့အတွင်း လုံးဝလွတ်လပ်စွာလုပ်ဆောင်မှုကို ရရှိသောကြောင့်၊ အစုအဝေး၏စွမ်းဆောင်ရည်အတွက် သူကိုယ်တိုင်တာဝန်ယူပါသည်။ ပြီးတော့ ဒီမှာ အရာအားလုံးကို ဖြတ်ဖို့ အရမ်းလွယ်တယ်။
• ဒုတိယအချက်မှာ ပေါင်းစည်းမှုမရှိခြင်းပင်ဖြစ်သည်။ လူကြိုက်များသော virtualization ပလပ်ဖောင်းမပါဘဲ Kubernetes ကို run ပါက၊ ပရိုဂရမ်၏ အကျိုးကျေးဇူးအားလုံးကို ရရှိမည်မဟုတ်ပါ။ Persistent Volumes နှင့် Load Balancer ဝန်ဆောင်မှုများကို အသုံးပြုခြင်းကဲ့သို့သော။

ပုံ 2. k8s ဗိသုကာ

ရောင်းချသူထံမှ Kubernetes

cloud ဝန်ဆောင်မှုပေးသူနှင့် ပေါင်းစည်းခြင်းသည် ရွေးချယ်စရာနှစ်ခုကို ပေးသည်-

• ပထမဦးစွာ၊ လူတစ်ဦးသည် "create cluster" ခလုတ်ကို ရိုးရိုးရှင်းရှင်း နှိပ်နိုင်ပြီး အသုံးပြုရန် အသင့်ဖြစ်နေပြီဖြစ်သော အစုအဝေးတစ်ခုကို ရယူနိုင်သည်။
• ဒုတိယအနေနှင့်၊ ရောင်းချသူကိုယ်တိုင်က အစုအဝေးကို တပ်ဆင်ပြီး cloud နှင့် ပေါင်းစည်းမှုကို သတ်မှတ်ပေးသည်။

ဒီမှာ ဘယ်လိုဖြစ်တာလဲ။ အစုအဝေးကို စတင်သည့် အင်ဂျင်နီယာသည် သူလိုအပ်သည့် လုပ်သားအရေအတွက်နှင့် မည်သို့သော ကန့်သတ်ချက်များဖြင့် သတ်မှတ်ပေးသည် (ဥပမာ၊ အလုပ်သမား ၅ ဦး၊ တစ်ဦးစီတွင် CPU 5 လုံး၊ RAM 10 GB နှင့် ဒစ်ခ် 16 GB ဟုဆိုသည်)။ ထို့နောက် ဖွဲ့စည်းပြီးသော အစုအဝေးသို့ ဝင်ရောက်ခွင့်ရရှိမည်ဖြစ်သည်။ ဤကိစ္စတွင်၊ ဝန်ကိုစတင်လိုက်သောအလုပ်သမားများကို client ထံလုံးဝလွှဲပြောင်းပေးသော်လည်း၊ စီမံခန့်ခွဲမှုလေယာဉ်တစ်ခုလုံးသည် ရောင်းချသူ၏တာဝန်ဖြစ်သည် (ဝန်ဆောင်မှုကိုစီမံထားသောဝန်ဆောင်မှုပုံစံအတိုင်းပေးမည်ဆိုပါက)။

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

ပုံ 3။ cloud ဝန်ဆောင်မှုပေးသူထံမှ Kubernetes အစုအဝေး၏ ဥပမာ

ရွေးချယ်ရမည့်အရာ- ပွင့်လင်းအရင်းအမြစ် သို့မဟုတ် ရောင်းချသူ

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

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

ဆောင်းပါးကို #CloudMTS ဝန်ဆောင်မှုပေးသူ၏ Containerum ဝန်ဆောင်မှု၏ ဦးဆောင်ဗိသုကာပညာရှင် Dmitry Krasnov မှ ပြင်ဆင်ထားပါသည်။

source: www.habr.com