ခေတ်မီအခြေခံအဆောက်အအုံ- ပြဿနာများနှင့် အလားအလာ

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

ပါဝင်သူများ:

• ITSumma ၏ CEO Evgeniy Potapov. ၎င်း၏ဖောက်သည်များ၏ ထက်ဝက်ကျော်သည် ရွေ့လျားနေပြီး သို့မဟုတ် Kubernetes သို့ ပြောင်းလိုကြသည်။
• Dmitry Stolyarov, CTO "Flant". ကွန်တိန်နာစနစ်ဖြင့် လုပ်ကိုင်သော အတွေ့အကြုံ 10+ နှစ်ရှိရမည်။
• Denis Remchukov (aka Eric Oldmann)၊ COO argotech.io၊ RAO UES ဟောင်း. “သွေးထွက်သံယို” လုပ်ငန်းကိစ္စများကို ဆွေးနွေးမည်ဟု ကတိပြုခဲ့သည်။
• Andrey Fedorovsky, CTO "News360.com"ကုမ္ပဏီကို အခြားကစားသမားတစ်ဦးမှ ဝယ်ယူပြီးနောက် ML နှင့် AI ပရောဂျက်များနှင့် အခြေခံအဆောက်အအုံများစွာအတွက် သူတာဝန်ယူသည်။
• Ivan Kruglov၊ စနစ်အင်ဂျင်နီယာဟောင်း၊ Booking.com။Kubernetes ကို သူ့လက်နဲ့ အများကြီးလုပ်ခဲ့တဲ့ အတူတူပါပဲ။

အပြင်အဆင်များ

• ပါဝင်သူများ၏ ကွန်တိန်နာများနှင့် တီးမှုတ်ခြင်းဆိုင်ရာ ထိုးထွင်းသိမြင်မှု (Docker၊ Kubernetes စသည်)၊ လက်တွေ့စမ်းသပ်ခဲ့တာတွေ၊
• ဖြစ်ရပ်- ကုမ္ပဏီသည် နှစ်ပေါင်းများစွာ အခြေခံအဆောက်အအုံ ဖွံ့ဖြိုးတိုးတက်ရေး အစီအစဉ်ကို တည်ဆောက်နေပါသည်။ ကွန်တိန်နာများနှင့် Kuber သို့ တည်ဆောက်ရန် (သို့မဟုတ် လက်ရှိ) အခြေခံအဆောက်အအုံကို တည်ဆောက်ရန် (သို့မဟုတ်) ရွှေ့ပြောင်းခြင်း ရှိ၊ မရှိ မည်ကဲ့သို့ ဆုံးဖြတ်ရမည်နည်း။
• cloud-ဇာတိကမ္ဘာရှိ ပြဿနာများ၊ လွဲမှားနေသည့်အရာများ၊ မနက်ဖြန် ဘာဖြစ်မည်ကို စိတ်ကူးကြည့်ကြပါစို့။

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

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

“ဘယ်သူမှ မသိသေးတဲ့အချိန်မှာ (Kubernetes. - Ed.) ဆီကို ရောက်ခဲ့တယ်။ သူမရှိတဲ့အချိန်မှာတောင် ငါတို့က သူ့ဆီရောက်လာတယ်။ ငါတို့အရင်ကလိုချင်ခဲ့တာ" Dmitry Stolyarov

Reddit.com မှ ဓာတ်ပုံ

လွန်ခဲ့သော 5-10 နှစ်က ကိရိယာများစွာရှိခဲ့ပြီး စံနှုန်းတစ်ခုမျှမရှိပေ။ ခြောက်လတိုင်း ထုတ်ကုန်အသစ်တစ်ခု သို့မဟုတ် တစ်ခုထက်ပို၍ ပေါ်လာသည်။ ပထမ Vagrant၊ ထို့နောက် ဆား၊ စားဖိုမှူး၊ ရုပ်သေး၊ ... "ပြီး ခြောက်လတိုင်း မင်းရဲ့ အခြေခံအဆောက်အအုံကို ပြန်ဆောက်တယ်။ သင့်တွင် configs အသစ်ပြန်ရေးရန် အမြဲအလုပ်ရှုပ်နေသော စီမံခန့်ခွဲသူငါးဦးရှိသည်” ဟု Andrey Fedorovsky က ပြန်ပြောပြသည်။ Docker နှင့် Kubernetes တို့သည် ကျန်အရာအားလုံးကို “လူများ” နေကြသည်ဟု သူယုံကြည်သည်။ Docker သည် ပြီးခဲ့သည့်ငါးနှစ်အတွင်း၊ Kubernetes ၏နောက်ဆုံးနှစ်နှစ်အတွင်း စံတစ်ခုဖြစ်လာခဲ့သည်။ ပြီးတော့ ဒါက လုပ်ငန်းအတွက် ကောင်းပါတယ်။.

Dmitry Stolyarov နှင့်သူ၏အဖွဲ့သည် Kuber ကိုနှစ်သက်သည်။ သူတို့သည် ထိုကိရိယာမပေါ်မီတွင် ထိုကဲ့သို့သောကိရိယာကို အလိုရှိကြပြီး ယင်းအကြောင်းကို မည်သူမျှမသိသောအခါတွင် ၎င်းတို့ထံရောက်လာခဲ့သည်။ လောလောဆယ်တွင်၊ အဆင်ပြေစေရန်အတွက်၊ ၎င်းတို့သည် Kubernetes ကို သူနှင့်အတူ အကောင်အထည်ဖော်မည်မဟုတ်ကြောင်း နားလည်ပါက ဖောက်သည်တစ်ဦးကို ၎င်းတို့က လက်ခံမည်မဟုတ်ပါ။ တစ်ချိန်တည်းမှာပင်၊ Dmitry ၏အဆိုအရ၊ ကုမ္ပဏီသည် "ကြောက်မက်ဖွယ်ကောင်းသောအမွေအနှစ်ကိုပြန်လည်ဖန်တီးခြင်းနှင့်ပတ်သက်သောကြီးမားသောအောင်မြင်မှုဇာတ်လမ်းများစွာရှိသည်။"

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

ကံမကောင်းစွာပဲ၊ ငါတို့ဘဝမှာ အရာရာတိုင်းအတွက် ပေးဆပ်ရမယ်။ Ivan Kruglov ယုံကြည်သကဲ့သို့ ဖွံ့ဖြိုးပြီး အခြေခံအဆောက်အဦရှိသော ကုမ္ပဏီတစ်ခု၏ Kubernetes သို့ ကူးပြောင်းခြင်းနှင့်ပတ်သက်၍ ဤအခွန်သည် ကြီးမားပါသည်။ သူသည် သမားရိုးကျ အခြေခံအဆောက်အအုံတစ်ခုနှင့် Kuber ဖြင့် ကုမ္ပဏီနှစ်ခုလုံးတွင် လွတ်လပ်စွာ အလုပ်လုပ်နိုင်သည်။ အဓိကကတော့ ကုမ္ပဏီရဲ့ သွင်ပြင်လက္ခဏာတွေနဲ့ စျေးကွက်ကို နားလည်ဖို့ပါပဲ။ သို့သော် ဥပမာအားဖြင့်၊ Kubernetes ကို မည်သည့် container orchestration tool တွင်မဆို ယေဘူယျဖော်ပြမည့် Evgeny Potapov အတွက်၊ ထိုသို့သောမေးခွန်းမျိုး မပေါ်ပေါက်ပါ။

Object-oriented programming သည် ရှုပ်ထွေးသော application များကို programming နည်းလမ်းတစ်ခုအဖြစ် ပေါ်လာသောအခါတွင် Evgeniy သည် 1990 ခုနှစ်များအတွင်း အခြေအနေနှင့် ဥပမာတစ်ခုကို ရေးဆွဲခဲ့သည်။ ထိုအချိန်တွင် ဆွေးနွေးငြင်းခုံမှုများ ဆက်လက်ဖြစ်ပွားခဲ့ပြီး OOP ကို ​​ပံ့ပိုးပေးသည့် ကိရိယာအသစ်များ ထွက်ပေါ်လာခဲ့သည်။ ထို့နောက်တွင် monolithic အယူအဆမှ ရုန်းထွက်ရန် နည်းလမ်းတစ်ခုအဖြစ် microservices များ ပေါ်ထွက်လာခဲ့သည်။ ယင်းက တစ်ဖန် ကွန်တိန်နာနှင့် ကွန်တိန်နာ စီမံခန့်ခွဲမှု ကိရိယာများ ပေါ်ပေါက်လာခဲ့သည်။ "မိုက်ခရိုဆားဗစ်အက်ပလီကေးရှင်းလေးတစ်ခုရေးရကျိုးနပ်လားဆိုတာ မေးခွန်းထုတ်စရာမရှိတဲ့အချိန်ကို မကြာခင်ရောက်လာတော့မယ်လို့ ကျွန်တော်ထင်ပါတယ်" ဟု ၎င်းက ယုံကြည်ပါသည်။ အလားတူပင်၊ Docker နှင့် Kubernetes တို့သည် ရွေးချယ်စရာမလိုအပ်ဘဲ နောက်ဆုံးတွင် စံဖြေရှင်းချက်ဖြစ်လာမည်ဖြစ်သည်။

နိုင်ငံမဲ့ ဒေတာဘေ့စ်ပြဿနာ

ဓာတ်ပုံ Twitter- Unsplash ရှိ @jankolario

ယခုအချိန်တွင် Kubernetes တွင် ဒေတာဘေ့စ်များလည်ပတ်ရန်အတွက် ချက်ပြုတ်နည်းများစွာရှိသည်။ I/O disk နဲ့ အလုပ်လုပ်တဲ့ အပိုင်းကို ဒေတာဘေ့စ်ရဲ့ အပလီကေးရှင်းအပိုင်းနဲ့ အခြေအနေအရ ဘယ်လိုခွဲရမလဲဆိုတာတောင်မှ သိနိုင်ပါတယ်။ အနာဂတ်တွင် ဒေတာဘေ့စ်များသည် အလွန်ပြောင်းလဲသွားလိမ့်မည်၊ အစိတ်အပိုင်းတစ်ခုကို Docker နှင့် Kubernetes မှတစ်ဆင့် ကြိုးကိုင်ထားမည်ဖြစ်ပြီး၊ အစိတ်အပိုင်းတစ်ခုအား Docker နှင့် Kubernetes တို့မှ ခွဲထုတ်ကာ သီးခြားဆော့ဖ်ဝဲမှတစ်ဆင့် သိုလှောင်မှုအပိုင်းကို ပံ့ပိုးပေးမည်ဖြစ်သောကြောင့် အနာဂတ်တွင် ဒေတာဘေ့စ်များသည် အလွန်ပြောင်းလဲသွားလိမ့်မည်ဖြစ်နိုင်ပါသလား။ ? အခြေခံများကို ထုတ်ကုန်တစ်ခုအဖြစ် ပြောင်းလဲမည်လား။

ဤဖော်ပြချက်သည် တန်းစီခြင်းစီမံခန့်ခွဲမှုနှင့် ဆင်တူသော်လည်း ရိုးရာဒေတာဘေ့စ်များတွင် အချက်အလက်များ၏ ယုံကြည်စိတ်ချရမှုနှင့် ထပ်တူပြုမှုများအတွက် လိုအပ်ချက်များမှာ ပိုမိုမြင့်မားသည်ဟု Andrey က ယုံကြည်သည်။ ပုံမှန်ဒေတာဘေ့စ်များတွင် Cache hit အချိုးသည် 99% ရှိပါသည်။ အလုပ်သမားတစ်ဦး ကျသွားပါက အသစ်တစ်ခု စတင်မည်ဖြစ်ပြီး၊ ကက်ရှ်သည် အစမှ စတင်၍ “နွေးသည်” ဖြစ်သည်။ ကက်ရှ်ကို ပူနွေးလာသည်အထိ အလုပ်သမားသည် ဖြည်းညှင်းစွာ အလုပ်လုပ်သည်၊ ဆိုလိုသည်မှာ ၎င်းကို အသုံးပြုသူအား တင်ဆောင်၍မရပါ။ အသုံးပြုသူ load မရှိသော်လည်း၊ ကက်ရှ်သည် ပူနွေးလာမည်မဟုတ်ပေ။ ဆိုးတဲ့စက်ဝိုင်းတစ်ခုပါပဲ။

Dmitry သည် အခြေခံအားဖြင့် သဘောမတူသည် - အထမြောက်ခြင်းနှင့် ခွဲဝေပေးခြင်းသည် ပြဿနာကို ဖြေရှင်းပေးသည်။ သို့သော် Andrey က အဖြေသည် လူတိုင်းအတွက် မသင့်လျော်ကြောင်း အခိုင်အမာဆိုသည်။ အချို့သောအခြေအနေများတွင်၊ quorum သည် သင့်လျော်သော်လည်း ၎င်းသည် ကွန်ရက်ပေါ်တွင် အပိုဝန်ကို တင်စေသည်။ NoSQL ဒေတာဘေ့စ်သည် ကိစ္စတိုင်းတွင် မသင့်လျော်ပါ။

တွေ့ဆုံပွဲတွင် ပါဝင်သူများကို စခန်းနှစ်ခု ခွဲထားသည်။

Denis နှင့် Andrey တို့သည် ဒစ်ခ် - ဒေတာဘေ့စ်စသည်ဖြင့် ရေးသားသမျှသည် လက်ရှိ Kuber ဂေဟစနစ်တွင် လုပ်ဆောင်ရန် မဖြစ်နိုင်ကြောင်း ငြင်းခုံကြသည်။ Kubernetes တွင် ထုတ်လုပ်မှုဒေတာ၏ ခိုင်မာမှုနှင့် ညီညွတ်မှုကို ထိန်းသိမ်းထားရန် မဖြစ်နိုင်ပေ။ ဤသည်မှာ အခြေခံအင်္ဂါရပ်တစ်ခုဖြစ်သည်။ ဖြေရှင်းချက်- ပေါင်းစပ်အခြေခံအဆောက်အအုံ။

MongoDB နှင့် Cassandra ကဲ့သို့သော ခေတ်မီသော cloud မူရင်းဒေတာဘေ့စ်များ သို့မဟုတ် Kafka သို့မဟုတ် RabbitMQ ကဲ့သို့သော မက်ဆေ့ချ်တန်းစီမှုများပင် Kubernetes ပြင်ပတွင် အမြဲရှိနေသော ဒေတာစတိုးဆိုင်များ လိုအပ်ပါသည်။

Evgeniy ၏အရာဝတ္ထုများ- " Kubera ရှိ အခြေစိုက်စခန်းများသည် ရုရှားနိုင်ငံ၌ တိမ်တိုက်မွေးစားခြင်း မရှိဟူသောအချက်နှင့် ဆက်စပ်လျက်ရှိသော ရုရှနိုင်ငံအနီး သို့မဟုတ် လုပ်ငန်းနီးသော ထိခိုက်ဒဏ်ရာရမှုတစ်ခုဖြစ်သည်။" အနောက်နိုင်ငံရှိ အသေးစား သို့မဟုတ် အလတ်စား ကုမ္ပဏီများသည် Cloud ဖြစ်သည်။ Amazon RDS ဒေတာဘေ့စ်များသည် Kubernetes နှင့် သင်ကိုယ်တိုင်လုပ်ဆောင်ခြင်းထက် ပိုမိုလွယ်ကူသည်။ ရုရှားတွင် ၎င်းတို့သည် Kuber ကို အသုံးပြု၍ တိရစ္ဆာန်ရုံကို ဖယ်ရှားရန် ကြိုးပမ်းနေချိန်တွင် ၎င်းထံသို့ အခြေစိုက်စခန်းများ လွှဲပြောင်းပေးသည်။

Kubernetes တွင် မည်သည့်ဒေတာဘေ့စ်ကိုမျှ သိမ်းဆည်းထားနိုင်မည်မဟုတ်ကြောင်းကို Dmitry က သဘောမတူခဲ့သည်- “အခြေခံသည် အခြေခံနှင့်မတူပါ။ ဧရာမဆက်စပ်ဒေတာဘေ့စ်တစ်ခုကို သင်တွန်းလိုက်လျှင် မည်သည့်အခြေအနေမျိုးတွင်မှ မရှိပါ။ တစ်ပိုင်းတစ်ပိုင်းဘဝအတွက် စိတ်ပိုင်းဆိုင်ရာပြင်ဆင်ထားသည့် သေးငယ်ပြီး တိမ်တိုက်ဇာတိတစ်ခုခုကို တွန်းပို့ပါက အရာအားလုံး အဆင်ပြေသွားမည်ဖြစ်သည်။" Docker သို့မဟုတ် Kuber အတွက် ဒေတာဘေ့စ် စီမံခန့်ခွဲမှု ကိရိယာများသည် အဆင်သင့်မဖြစ်သေးသောကြောင့် ကြီးမားသော အခက်အခဲများ ဖြစ်ပေါ်လာကြောင်း Dmitry က ဖော်ပြခဲ့သည်။

တစ်နည်းဆိုသော် Ivan သည် နိုင်ငံပိုင်နှင့် နိုင်ငံမဲ့ သဘောတရားများမှ လွဲချော်နေသော်လည်း Kubernetes ရှိ လုပ်ငန်းဖြေရှင်းချက်များ၏ ဂေဟစနစ်သည် အဆင်သင့်မဖြစ်သေးကြောင်း သေချာပါသည်။ Kuber နှင့်အတူ၊ ဥပဒေပြုရေးနှင့် စည်းကမ်းသတ်မှတ်ချက်များကို ထိန်းသိမ်းရန် ခက်ခဲသည်။ ဥပမာအားဖြင့်၊ ဆာဗာများတွင် ထည့်သွင်းထားသော ဟာ့ဒ်ဝဲများအထိ တင်းကျပ်သော server identification အာမခံချက်များ လိုအပ်သည့် အထောက်အထား ပံ့ပိုးမှုဖြေရှင်းချက်ကို ပြုလုပ်ရန် မဖြစ်နိုင်ပါ။ ဒီနယ်မြေက ဖွံ့ဖြိုးလာပေမယ့် ဖြေရှင်းချက်မရသေးပါ။
ပါဝင်သူများသည် သဘောမတူနိုင်သောကြောင့် ဤအပိုင်းတွင် ကောက်ချက်ဆွဲမည်မဟုတ်ပါ။ လက်တွေ့နမူနာအချို့ကို ပေးကြပါစို့။

ဖြစ်ရပ် ၁။ Kubera ပြင်ပအခြေစိုက်စခန်းများပါရှိသော "mega-regulator" ၏ ဆိုက်ဘာလုံခြုံရေး

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

ဖြစ်ရပ် ၂။ Booking.com ဒေတာဘေ့စ်များကို Kubernetes သို့ တစ်စိတ်တစ်ပိုင်း ရွှေ့ပြောင်းခြင်း။

Booking.com တွင်၊ ပင်မဒေတာဘေ့စ်သည် MySQL သည် အပြိုင်အဆိုင်ပုံတူကူးချခြင်းဖြစ်သည် - သခင်နှင့်ကျွန်များ၏အထက်တန်းအဆင့်တစ်ခုရှိသည်။ အိုင်ဗန် ကုမ္ပဏီမှ ထွက်ခွာချိန်တွင် အချို့သော ပျက်စီးမှုများဖြင့် “ပစ်သတ်ခံရ” နိုင်သည့် ကျွန်များကို လွှဲပြောင်းပေးရန် ပရောဂျက်တစ်ခု စတင်ခဲ့သည်။

ပင်မအခြေစိုက်စခန်းအပြင်၊ Kuber ပင်မရေစီးကြောင်းသို့မ၀င်မီကပင် ကိုယ်တိုင်ရေးထားသော တီးမှုတ်မှုဖြင့် Cassandra တပ်ဆင်မှုတစ်ခုပါရှိသည်။ ဤကိစ္စတွင် ပြဿနာမရှိသော်လည်း၊ ၎င်းသည် ပြည်တွင်း SSDs များတွင် ဆက်လက်တည်ရှိနေပါသည်။ တူညီသောဒေတာစင်တာအတွင်း၌ပင် အဝေးထိန်းသိမ်းဆည်းမှုကို ကြာမြင့်ချိန်ချိန်ညှိမှုပြဿနာကြောင့် အသုံးမပြုပါ။

ဒေတာဘေ့စ်များ၏ တတိယအတန်းအစားမှာ Booking.com ရှာဖွေရေးဝန်ဆောင်မှုဖြစ်ပြီး၊ ဝန်ဆောင်မှုတစ်ခုစီသည် ဒေတာဘေ့စ်တစ်ခုဖြစ်သည်။ ရှာဖွေရေးဝန်ဆောင်မှုကို Kuber သို့လွှဲပြောင်းရန် ကြိုးပမ်းရာတွင် မအောင်မြင်ပါ၊ အဘယ်ကြောင့်ဆိုသော် node တစ်ခုစီသည် "lift" နှင့် "warm up" ရန်ခက်ခဲသော 60-80 GB စက်တွင်းသိုလှောင်မှုဖြစ်သည်။

ရလဒ်အနေဖြင့် ရှာဖွေရေးအင်ဂျင်ကို Kubernetes သို့ လွှဲပြောင်းမပေးခဲ့ဘဲ၊ မကြာမီကာလအတွင်းတွင် ကြိုးပမ်းမှုအသစ်များရှိလာမည်ဟု Ivan မထင်ပါ။ MySQL ဒေတာဘေ့စ်ကို တစ်ဝက်တစ်ပျက် လွှဲပြောင်းခဲ့သည်- “ပစ်ခံရ” ရန် မကြောက်သော Slaves များသာ ဖြစ်သည်။ Cassandra သည် စုံလင်စွာ အခြေချနေထိုင်ခဲ့သည်။

ယေဘူယျဖြေရှင်းချက်မပါဘဲ အခြေခံအဆောက်အအုံရွေးချယ်မှု

ဓာတ်ပုံ Pexels မှ Manuel Geissinger

ကျွန်ုပ်တို့တွင် ကုမ္ပဏီအသစ်တစ်ခု သို့မဟုတ် အခြေခံအဆောက်အအုံ၏ တစ်စိတ်တစ်ပိုင်းကို ပုံစံဟောင်းဖြင့် တည်ဆောက်ထားသည့် ကုမ္ပဏီတစ်ခုဟုဆိုကြပါစို့။ ၎င်းသည် နှစ်ပေါင်းများစွာ အခြေခံအဆောက်အအုံ ဖွံ့ဖြိုးတိုးတက်ရေး အစီအစဉ်ကို တည်ဆောက်သည်။ ကွန်တိန်နာများနှင့် Kuber တွင် အခြေခံအဆောက်အအုံတည်ဆောက်ရန် ဆုံးဖြတ်ခြင်းအား မည်သို့ဆုံးဖြတ်သနည်း။

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

အိုင်ဗင်- “ကျွန်တော်က စျေးပိုသက်သာပေမယ့် ပိုမြန်တာကြောင့် cloud မှာ အခုပဲ ကုမ္ပဏီတစ်ခု စတင်တော့မှာ သေချာပါတယ်။ အကျိုးတူအရင်းရှင်စနစ် ဖွံ့ဖြိုးတိုးတက်မှုနှင့်အတူ၊ startup များသည် ငွေနှင့်ပတ်သက်သော ကြီးကြီးမားမားပြဿနာများ မရှိကြဘဲ အဓိကတာဝန်မှာ စျေးကွက်ကို သိမ်းပိုက်ရန်ဖြစ်သည်။

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

မည်သည့်ကိစ္စတွင်မဆို အခွန်ပေးဆောင်ရမည်ဖြစ်ပြီး အိုင်ဗန်သည် အနာဂတ်တွင် လျော့နည်းပေးဆောင်နိုင်စေမည့်သူကို ပေးဆောင်မည်ဖြစ်သည်။ “သူများတွေ ရွေ့လျားနေတဲ့ ရထားပေါ်မှာ ငါစီးနေရလို့ လောင်စာဆီထည့်ရမဲ့ တခြားရထားပေါ်ထိုင်ရင် ငါ ခရီးပိုဝေးသွားလိမ့်မယ်။" Ivan ကပြောပါတယ်။ ကုမ္ပဏီအသစ်ဖြစ်ပြီး၊ latency လိုအပ်ချက်များသည် ဆယ်ဂဏန်းမီလီစက္ကန့်များဖြစ်သောကြောင့် Ivan သည် ယနေ့ခေတ် classical databases များကို “ထုပ်ပိုးထားသည့်” အော်ပရေတာများဆီသို့ ကြည့်ရှုမည်ဖြစ်သည်။ ၎င်းတို့သည် ပျက်ကွက်ခြင်းစသည်ဖြင့် သူ့အလိုလိုပြောင်းသွားသည့် ပုံတူကွင်းဆက်တစ်ခုကို ပြုစုပျိုးထောင်ပေးသည်။

ဆာဗာနှစ်ခုပါသော ကုမ္ပဏီငယ်တစ်ခုအတွက် Kubera သည် အဓိပ္ပါယ်မရှိပါ” ဟု Andrey ကဆိုသည်။ သို့သော် ၎င်းသည် ဆာဗာရာနှင့်ချီ သို့မဟုတ် ထို့ထက်ပို၍ကြီးထွားရန် စီစဉ်နေပါက ၎င်းသည် အလိုအလျောက်စနစ်နှင့် အရင်းအမြစ်စီမံခန့်ခွဲမှုစနစ် လိုအပ်ပါသည်။ 90% သည် ကုန်ကျစရိတ်နှင့် ထိုက်တန်ပါသည်။ ထိုမှတပါး, ဝန်နှင့်အရင်းအမြစ်များအဆင့်မခွဲခြားဘဲ။ ကွန်တိန်နာတီးမှုတ်ခြင်း ထုတ်ကုန်များဆီသို့ တဖြည်းဖြည်းကြည့်ရှုရန် သန်းနှင့်ချီသော ပရိသတ်သန်းပေါင်းများစွာရှိသော startup များမှ ကုမ္ပဏီကြီးများအထိ လူတိုင်းအတွက် အဓိပ္ပါယ်ရှိပေသည်။ “ဟုတ်တယ်၊ ဒါက တကယ့်ကို အနာဂတ်ပါပဲ” Andrey က သေချာပါတယ်။

Denis သည် အဓိက စံနှစ်ရပ်ကို ဖော်ပြခဲ့သည်- လည်ပတ်နိုင်စွမ်းနှင့် တည်ငြိမ်မှု။ သူသည် အလုပ်အတွက် အသင့်တော်ဆုံး ကိရိယာများကို ရွေးပေးလိမ့်မည်။ "ဒါဟာ မင်းဒူးပေါ်မှာ စုဝေးနေတဲ့ အမည်နာမတစ်ခု ဖြစ်နိုင်တယ်၊ ပြီးတော့ သူ့မှာ Nutanix Community Edition ပါရှိတယ်။ ၎င်းသည် နောက်ကွယ်ရှိ ဒေတာဘေ့စ်တစ်ခုပါရှိသော Kuber ရှိ အပလီကေးရှင်းပုံစံ၏ ဒုတိယစာကြောင်းဖြစ်နိုင်သည်၊ ၎င်းသည် ပုံတူကူးထားပြီး သတ်မှတ်ထားသော RTO နှင့် RPO ဘောင်များပါရှိသည်" (ပြန်လည်ရယူချိန်/အမှတ် ရည်ရွယ်ချက်များ - အနီးစပ်ဆုံး).

Evgeniy သည် အမှုထမ်းများနှင့် ဖြစ်နိုင်ချေရှိသော ပြဿနာကို ဖော်ထုတ်ခဲ့သည်။ လောလောဆယ်တွင် စျေးကွက်တွင် “အသည်း” ကို နားလည်သော အရည်အချင်းပြည့်မီသော ကျွမ်းကျင်သူများစွာ မရှိပါ။ အမှန်မှာ၊ ရွေးချယ်ထားသောနည်းပညာသည် ဟောင်းနေပါက၊ ဘဝကို ငြီးငွေ့ငြီးငွေ့နေသော လူလတ်ပိုင်းမှလွဲ၍ အခြားမည်သူ့ကိုမျှ ငှားရမ်းရန် ခက်ခဲသည်။ အခြားပါဝင်သူများက ဤအရာသည် ဝန်ထမ်းလေ့ကျင့်ရေးကိစ္စဖြစ်သည်ဟု ယုံကြည်ကြသည်။
ရွေးချယ်မှု၏မေးခွန်းကိုကျွန်ုပ်တို့ထည့်သွင်းပါက- Amazon RDS တွင်ဒေတာဘေ့စ်များပါရှိသောကုမ္ပဏီငယ်တစ်ခုအား Public Cloud တွင်ဖွင့်လှစ်ရန် သို့မဟုတ် Kubernetes ရှိဒေတာဘေ့စ်များနှင့်အတူ "အနှစ်သာရတွင်" ကိုဖွင့်ရန်၊ ချို့ယွင်းချက်အချို့ရှိနေသော်လည်း Amazon RDS သည်ပါဝင်သူများ၏ရွေးချယ်မှုဖြစ်လာခဲ့သည်။

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

Kubernetes အသုံးပြုမှုကို အကဲဖြတ်ခြင်း။

နားထောင်သူ Anton Zhbankov သည် Kubernetes မှ တောင်းပန်သည့်မေးခွန်းကို မေးခဲ့သည်- ဖြစ်နိုင်ခြေလေ့လာမှုကို သင်မည်ကဲ့သို့ ရွေးချယ်ပြီး လုပ်ဆောင်ခဲ့သနည်း။ အဘယ်ကြောင့် Kubernetes၊ အဘယ်ကြောင့် virtual machines များမဟုတ်သနည်း၊

ဓာတ်ပုံ Unsplash တွင် Tatyana Eremina

Dmitry နဲ့ Ivan က ဖြေပါတယ်။ ဖြစ်ရပ်နှစ်ခုစလုံးတွင်၊ အစမ်းသုံးခြင်းနှင့် အမှားအယွင်းများမှတဆင့် Kubernetes သို့ ပါဝင်သူနှစ်ဦးစလုံးမှ ရောက်ရှိလာသောကြောင့် ဆုံးဖြတ်ချက်များ ဆက်တိုက်ပြုလုပ်ခဲ့သည်။ ယခုအခါ စီးပွားရေးလုပ်ငန်းများသည် Kuber သို့ လွှဲပြောင်းရန် အဓိပ္ပာယ်ရှိသော ဆော့ဖ်ဝဲလ်ကို လွတ်လပ်စွာ တီထွင်ထုတ်လုပ်လာကြသည်။ ကျွန်ုပ်တို့သည် 1C ကဲ့သို့သော ဂန္တဝင်ပြင်ပအဖွဲ့အစည်းစနစ်များအကြောင်း ပြောနေခြင်းမဟုတ်ပါ။ ဆော့ဖ်ဝဲရေးသားသူများသည် မရပ်မနား စဉ်ဆက်မပြတ် တိုးတက်မှုဖြင့် ထုတ်ဝေမှုများ အမြန်ပြုလုပ်ရန် လိုအပ်သည့်အခါ Kubernetes က ကူညီပေးသည်။

Andrey ၏အဖွဲ့သည် virtual machines များကိုအခြေခံ၍ အရွယ်တင်နိုင်သောအစုအဝေးတစ်ခုကိုဖန်တီးရန်ကြိုးစားခဲ့သည်။ Node များသည် တစ်ခါတစ်ရံတွင် အစုအဝေးပြိုကွဲသွားစေရန် dominoes များကဲ့သို့ ကျဆင်းသွားပါသည်။ "သီအိုရီအရ၊ မင်းအဲဒါကို ပြီးအောင်လုပ်ပြီး မင်းလက်နဲ့ထောက်နိုင်တယ်၊ ဒါပေမယ့် ပျင်းတယ်။ စျေးကွက်ထဲမှာ မင်းကို သေတ္တာထဲက ရုန်းထွက်နိုင်စေမယ့် ဖြေရှင်းချက်တစ်ခုရှိရင်၊ အဲဒါကို လိုက်ဖို့ ကျေနပ်ပါတယ်။ ပြီးတော့ ရလဒ်အနေနဲ့ ကျွန်တော်တို့ ပြောင်းသွားတယ်” လို့ Andrey က ပြောပါတယ်။

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

အဘယ်အရာက ကျွန်ုပ်တို့ကို စောင့်ကြိုနေသနည်း။

ဓာတ်ပုံ Unsplash တွင် Beamer ဆွဲပါ။

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

Linux လောကအတွက် Ubuntu ကဲ့သို့ tool တစ်ခုရှိလာမည့်အချိန်ရောက်လာမည်ဟု သင်ထင်ပါသလား။ ကွန်တိန်နာတစ်လုံးတည်းနှင့် စုစည်းမှုကိရိယာတစ်ခု Kuber ပါဝင်လိမ့်မည်ဖြစ်နိုင်သည်။ ၎င်းသည် ပရဝုဏ်အတွင်း တိမ်များကို တည်ဆောက်ရန် လွယ်ကူစေမည်ဖြစ်သည်။

Ivan မှအဖြေကိုပေးခဲ့သည်- "Google သည် ယခုအခါ Anthos ကိုတည်ဆောက်နေပါသည် - ၎င်းသည် cloud ကိုဖြန့်ကျက်ပြီး Kuber၊ Service Mesh၊ စောင့်ကြည့်ခြင်းပါဝင်သည့် ၎င်းတို့၏ထုပ်ပိုးထားသောကမ်းလှမ်းချက်ဖြစ်သည် - ပြင်ပအသေးစားဝန်ဆောင်မှုများအတွက်လိုအပ်သော ဟာ့ဒ်ဝဲအားလုံး" ငါတို့က အနာဂတ်မှာ နီးနေပြီ။"

Denis သည် ကွန်တိန်နာထည့်သွင်းခြင်းမပြုဘဲ အလားတူလုပ်ဆောင်မှုများကို ရင်ဆိုင်နိုင်သည့် vRealize Suite ထုတ်ကုန်နှင့်အတူ Nutanix နှင့် VMWare ကိုဖော်ပြခဲ့သည်။

"နာကျင်မှု" ကိုလျှော့ချခြင်းနှင့်အခွန်လျှော့ချခြင်းတို့သည်တိုးတက်မှုများကိုမျှော်လင့်နိုင်သည့်နယ်ပယ်နှစ်ခုဖြစ်သည်ဟု Dmitry ကသူ၏အမြင်ကိုပြောကြားခဲ့သည်။

ဆွေးနွေးချက်ကို အကျဉ်းချုံ့ရန်၊ ကျွန်ုပ်တို့သည် ခေတ်မီအခြေခံအဆောက်အအုံဆိုင်ရာ အောက်ပါပြဿနာများကို မီးမောင်းထိုးပြသည်-

• ပါဝင်သူ သုံးဦးက ချက်ချင်းဆိုသလို ပြဿနာတစ်ခုကို ဖော်ထုတ်ခဲ့သည်။
• Docker သည် Python၊ အပလီကေးရှင်းဆာဗာများနှင့် အစိတ်အပိုင်းများစွာကို ဗားရှင်းများစွာဖြင့် အဆုံးသတ်နိုင်ခြေ အပါအဝင် လုံခြုံရေးဆိုင်ရာ ပံ့ပိုးမှုဆိုင်ရာ ပြဿနာများ။
  အပိုသုံးစွဲခြင်း သည် သီးခြားအစည်းအဝေးတွင် ဆွေးနွေးရန် ပိုကောင်းသည်။
  စုစည်းမှုစနစ်သည် ရှုပ်ထွေးသောဂေဟစနစ်ဖြစ်သောကြောင့် သင်ယူမှုစိန်ခေါ်မှုတစ်ခုဖြစ်သည်။
  စက်မှုလုပ်ငန်းတွင် အဖြစ်များသော ပြဿနာမှာ ကိရိယာများကို အလွဲသုံးစားလုပ်ခြင်း ဖြစ်သည်။

  ကျန်တဲ့ ကောက်ချက်တွေက မင်းအပေါ်မှာ မူတည်တယ်။ Docker + Kubernetes ပေါင်းစပ်မှုသည် စနစ်၏ "ဗဟို" အစိတ်အပိုင်းဖြစ်လာရန် မလွယ်ကူကြောင်း ခံစားချက်ရှိနေဆဲဖြစ်သည်။ ဥပမာအားဖြင့်၊ ကွန်တိန်နာနှင့် တီးမှုတ်ခြင်းအကြောင်း မပြောနိုင်သော ဟာ့ဒ်ဝဲပေါ်တွင် ဦးစွာ လည်ပတ်မှုစနစ်များကို ထည့်သွင်းထားသည်။ အနာဂတ်တွင်၊ လည်ပတ်မှုစနစ်များနှင့် ကွန်တိန်နာများသည် cloud စီမံခန့်ခွဲမှုဆော့ဖ်ဝဲနှင့် ပေါင်းစည်းသွားမည်ဖြစ်သည်။

  
  ဓာတ်ပုံ Pexels မှ Gabriel Santos Fotografia

  ဒီအခွင့်အရေးကို အမေ့ကို နှုတ်ဆက်ပြီး ကျွန်တော်တို့မှာ Facebook Group တစ်ခုရှိတယ်ဆိုတာ သတိပေးချင်ပါတယ်။ "ကြီးမားသော IT ပရောဂျက်များကို စီမံခန့်ခွဲခြင်းနှင့် ဖွံ့ဖြိုးတိုးတက်ရေး"၊ချန်နယ် @feedmeto အမျိုးမျိုးသော နည်းပညာဘလော့ဂ်များမှ စိတ်ဝင်စားဖွယ်ကောင်းသော စာစောင်များနှင့်အတူ။ ငါ့ချန်နယ် @rybakalexeyထုတ်ကုန်ကုမ္ပဏီများတွင် ဖွံ့ဖြိုးတိုးတက်မှုကို စီမံခန့်ခွဲခြင်းအကြောင်းကို ကျွန်ုပ်ပြောဆိုရာ။

source: www.habr.com