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

ကျွန်ုပ်တို့သည် B2B နှင့် B2C အတွက် အွန်လိုင်းကုန်သွယ်မှုနှင့် fintech ထုတ်ကုန်များအတွက် ဝန်ဆောင်မှုများကို ဖော်ဆောင်ပေးသော fintech ကုမ္ပဏီ Exness မှဖြစ်သည်။ ကျွန်ုပ်တို့၏ R&D တွင် မတူညီသောအဖွဲ့များစွာရှိပြီး ဖွံ့ဖြိုးတိုးတက်ရေးဌာနတွင် ဝန်ထမ်း 100+ ရှိသည်။

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

ကျွန်ုပ်တို့၏လှုံ့ဆော်မှု

ဘာလောင်လဲ။ ဘယ်သူမှ မဖြေနိုင်ဘူး။ မီးဖိုက ဘယ်မှာလဲ နားလည်ရခက်ပါတယ်။ ဘယ်တုန်းက မီးလောင်ခဲ့တာလဲ။ သင်သိနိုင်သော်လည်းချက်ချင်းမဟုတ်ပါ။ 

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

ကျွန်ုပ်တို့၏ developer များသည် အရည်အချင်းရှိသူများဖြစ်သည်။ သူတို့ဟာ ကုမ္ပဏီကို အမြတ်အစွန်း ပေးမယ့် ဝန်ဆောင်မှုကောင်းတွေ ပေးတယ်။ သို့သော် အပလီကေးရှင်းများပါရှိသော ကွန်တိန်နာများ လမ်းလွဲသွားသောအခါတွင် ပျက်ကွက်မှုများ ရှိပါသည်။ ကွန်တိန်နာတစ်ခုသည် CPU အလွန်အကျွံစားသုံးသည်၊ နောက်တစ်ခုသည် ကွန်ရက်ကိုစားသုံးသည်၊ တတိယတစ်ခုသည် I/O လုပ်ဆောင်ချက်များကို စားသုံးသည်၊ စတုတ္ထတစ်ခုသည် sockets များနှင့်လုပ်ဆောင်သည်များကို လုံးဝမသိရပါ။ အားလုံးပြုတ်ကျပြီး သင်္ဘောနစ်သွားတယ်။ 

အေးဂျင့်များ

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

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

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

အေးဂျင့်များသည် မတူညီသောပုံများ (Debian၊ Alpine၊ Centos စသည်) တို့ကို ပံ့ပိုးပေးသည့် မတူညီသော စုစည်းမှုစနစ်များတွင် အလုပ်လုပ်နိုင်သော လည်ပတ်မှုနှင့် ပြုပြင်ထိန်းသိမ်းမှုအတွက် အသုံးဝင်မှုများကို ဆိုလိုသည်။

နောက်ဆုံးတွင်၊ အေးဂျင့်များသည် Docker ဖိုင်များပါ၀င်သည့် ရိုးရှင်းသော CI/CD ကို ပံ့ပိုးရပါမည်။ မဟုတ်ပါက၊ သင်္ဘောသည် ကွဲသွားလိမ့်မည်၊ အကြောင်းမှာ ကွန်တိန်နာများကို "ကောက်နေသော" သံလမ်းများအတိုင်း ပို့ဆောင်ပေးမည်ဖြစ်သည်။

လုပ်ငန်းစဉ်တည်ဆောက်ပြီး ပစ်မှတ်ပုံသဏ္ဌာန်စက်

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

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

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

ဒီနည်းလမ်းက ဘာကောင်းလဲ။ 

• ပထမဦးစွာ build tools ၏ full version control - build container၊ script နှင့် distribution ဗားရှင်းများ။ 
• ဒုတိယအနေဖြင့်၊ ကျွန်ုပ်တို့သည် စံသတ်မှတ်ခြင်းကို အောင်မြင်ပြီးဖြစ်သည်- ကျွန်ုပ်တို့သည် ပုံစံပလိတ်များ၊ အလယ်အလတ်နှင့် အဆင်သင့်သုံးနိုင်သော ရုပ်ပုံများကို အလားတူနည်းဖြင့် ဖန်တီးပါသည်။ 
• တတိယအချက်၊ ကွန်တိန်နာများသည် ကျွန်ုပ်တို့ကို သယ်ဆောင်ရလွယ်ကူစေသည်။ ယနေ့ကျွန်ုပ်တို့သည် Gitlab ကိုအသုံးပြုပြီး မနက်ဖြန်တွင် TeamCity သို့မဟုတ် Jenkins သို့ပြောင်းမည်ဖြစ်ပြီး ကျွန်ုပ်တို့၏ကွန်တိန်နာများကို ထိုနည်းအတိုင်းလုပ်ဆောင်နိုင်မည်ဖြစ်သည်။ 
• စတုတ္ထ၊ မှီခိုအားထားမှု နည်းပါးအောင်၊ ကျွန်ုပ်တို့သည် ဖြန့်ဖြူးရေးကိရိယာများကို ကွန်တိန်နာတွင် ထည့်ထားရခြင်းမှာ တိုက်ဆိုင်မှုမဟုတ်ပေ။ အကြောင်းမှာ ယင်းက ၎င်းတို့ကို အင်တာနက်မှ အချိန်တိုင်း ဒေါင်းလုဒ်လုပ်ခြင်းကို ရှောင်ရှားနိုင်သောကြောင့် ဖြစ်သည်။ 
• ပဉ္စမအချက်အနေဖြင့်၊ တည်ဆောက်မှုအမြန်နှုန်း တိုးလာသည် - ဒေသန္တရပုံများ ပါရှိခြင်းကြောင့် ဒေါင်းလုဒ်ဆွဲရာတွင် အချိန်ဖြုန်းခြင်းမှ ရှောင်ရှားနိုင်စေပါသည်။ 

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

ကျွန်ုပ်တို့၏ တည်ဆောက်မှု လုပ်ငန်းစဉ်သည် မည်သို့အလုပ်လုပ်သနည်း။

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

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

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

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

 

တူညီသောကွန်တိန်နာအတွက် Docker နှင့် Kubernetes တွင် မတူညီသော လုပ်ငန်းစဉ်သစ်ပင်များ ရရှိသည်-

payload ကို S6 ၏ ကြီးကြပ်မှုအောက်တွင် လုပ်ဆောင်ပါသည်။ စုဆောင်းသူနှင့် ပွဲများကို အာရုံစိုက်ပါ - ၎င်းတို့သည် မှတ်တမ်းများနှင့် တိုင်းတာမှုများအတွက် တာဝန်ရှိသော ကျွန်ုပ်တို့၏ အေးဂျင့်များဖြစ်သည်။ Kubernetes တွင် ၎င်းတို့မရှိသော်လည်း Docker က လုပ်ဆောင်သည်။ အဘယ်ကြောင့်? 

“pod” ၏ သတ်မှတ်ချက်ကို လေ့လာကြည့်လျှင် (နောင်တွင် – Kubernetes pod)၊ မက်ထရစ်များနှင့် မှတ်တမ်းများ စုဆောင်းခြင်းဆိုင်ရာ လုပ်ဆောင်ချက်ကို လုပ်ဆောင်သည့် သီးခြား စုဆောင်းသည့် ကွန်တိန်နာတစ်ခု ပါရှိသည့် ဖြစ်ရပ်များ ကွန်တိန်နာကို ဘူးတစ်ခုတွင် လုပ်ဆောင်ထားသည်ကို တွေ့ရမည်ဖြစ်ပါသည်။ Kubernetes ၏ စွမ်းရည်များကို ကျွန်ုပ်တို့အသုံးပြုနိုင်သည်- ပေါ့ဒ်တစ်ခုတွင်၊ လုပ်ငန်းစဉ်တစ်ခုတည်းနှင့်/သို့မဟုတ် ကွန်ရက်နေရာတစ်ခုတွင် ကွန်တိန်နာများကို လုပ်ဆောင်နေသည်။ သင့်အေးဂျင့်များကို မိတ်ဆက်ပေးပြီး လုပ်ဆောင်ချက်အချို့ကို လုပ်ဆောင်ပါ။ တူညီသောကွန်တိန်နာကို Docker တွင်စတင်အသုံးပြုပါက၊ အေးဂျင့်များကိုပြည်တွင်းတွင်စတင်မည်ဖြစ်သောကြောင့်၊ ၎င်းသည် မှတ်တမ်းများနှင့် မက်ထရစ်များကိုပေးပို့နိုင်မည်ဖြစ်ပြီး၊ ၎င်းသည် output ကဲ့သို့တူညီသောစွမ်းရည်အားလုံးကိုရရှိမည်ဖြစ်သည်။ 

မက်ထရစ်များနှင့် မှတ်တမ်းများ

မက်ထရစ်များနှင့် မှတ်တမ်းများပေးပို့ခြင်းသည် ရှုပ်ထွေးသောအလုပ်ဖြစ်သည်။ သူမ၏ ဆုံးဖြတ်ချက်တွင် ရှုထောင့်များစွာရှိသည်။
အခြေခံအဆောက်အအုံသည် ဝန်ဆောင်ခကို အကောင်အထည်ဖော်ရန်အတွက် ဖန်တီးထားခြင်းဖြစ်ပြီး မှတ်တမ်းများ အစုလိုက်အပြုံလိုက်ပေးပို့ခြင်းအတွက် မဟုတ်ပါ။ ဆိုလိုသည်မှာ ဤလုပ်ငန်းစဉ်ကို ကွန်တိန်နာ အရင်းအမြစ် လိုအပ်ချက် အနည်းဆုံးဖြင့် လုပ်ဆောင်ရပါမည်။ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ developer များအား ကူညီရန်ကြိုးစားပါသည်- "Docker Hub container ကိုရယူပါ၊ ၎င်းကိုဖွင့်ပါ၊ နှင့်ကျွန်ုပ်တို့သည်မှတ်တမ်းများကိုပေးပို့နိုင်သည်။" 

ဒုတိယအချက်မှာ မှတ်တမ်းများ၏ ပမာဏကို ကန့်သတ်ခြင်း ဖြစ်သည်။ ကွန်တိန်နာအများအပြားတွင် မှတ်တမ်းများ၏ ပမာဏ မြင့်တက်လာပါက (အပလီကေးရှင်းသည် စက်ဝိုင်းတစ်ခုအတွင်း stack-trace ကိုထုတ်ပေးသည်)၊ CPU၊ ဆက်သွယ်ရေးလမ်းကြောင်းများနှင့် မှတ်တမ်းလုပ်ဆောင်ခြင်းစနစ်တွင် ဝန်တိုးလာကာ ၎င်းသည် host ၏လည်ပတ်မှုကို အကျိုးသက်ရောက်စေသည်။ host ပေါ်တွင်တစ်ခုလုံးနှင့်အခြားကွန်တိန်နာများ, ထို့နောက်တစ်ခါတစ်ရံ၎င်းသည် host ၏ "ပြိုလဲခြင်း" ကိုဖြစ်ပေါ်စေသည်။ 

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

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

Telegraf ဟုခေါ်သော open-source Go ဖြေရှင်းချက်ကို ကျွန်ုပ်တို့ ရွေးချယ်ခဲ့သည်။ ၎င်းသည် input channels အမျိုးအစား 140 ကျော် (input plugins) နှင့် output channels အမျိုးအစား 30 (output plugins) ကို ပံ့ပိုးပေးသည့် universal connector ဖြစ်သည်။ ကျွန်ုပ်တို့ ၎င်းကို အပြီးသတ်ပြီးပါပြီ၊ ယခု ကျွန်ုပ်တို့သည် ၎င်းကို Kubernetes ကို နမူနာအဖြစ် အသုံးပြုနည်းကို ပြောပြပါမည်။ 

ဆော့ဖ်ဝဲအင်ဂျင်နီယာတစ်ဦးသည် အလုပ်တာဝန်တစ်ခုအား ဖြန့်ချထားပြီး Kubernetes သည် ပေါ့ဒ်တစ်ခုဖန်တီးရန် တောင်းဆိုချက်ကို လက်ခံရရှိသည်ဆိုကြပါစို့။ ဤအချိန်တွင်၊ Collector ဟုခေါ်သော ကွန်တိန်နာကို pod တစ်ခုစီအတွက် အလိုအလျောက် ဖန်တီးသည် (ကျွန်ုပ်တို့သည် mutation webhook ကိုအသုံးပြုသည်)။ စုဆောင်းသူသည် ကျွန်ုပ်တို့၏ ကိုယ်စားလှယ်ဖြစ်သည်။ အစတွင်၊ ဤကွန်တိန်နာသည် Prometheus နှင့် မှတ်တမ်းစုဆောင်းမှုစနစ်တို့နှင့် အလုပ်လုပ်ရန် သူ့ကိုယ်သူ configure လုပ်သည်။

• ၎င်းကိုလုပ်ဆောင်ရန်၊ ၎င်းသည် pod မှတ်ချက်များကိုအသုံးပြုပြီး ၎င်း၏အကြောင်းအရာပေါ် မူတည်၍ Prometheus အဆုံးမှတ်တစ်ခုကို ဖန်တီး၊ 
• pod သတ်မှတ်ချက်နှင့် တိကျသော ကွန်တိန်နာဆက်တင်များကို အခြေခံ၍ ၎င်းသည် မှတ်တမ်းများကို မည်သို့ပေးပို့ရမည်ကို ဆုံးဖြတ်သည်။

Docker API မှတဆင့် ကျွန်ုပ်တို့သည် မှတ်တမ်းများကို စုဆောင်းပါသည်- developer များသည် ၎င်းတို့ကို stdout သို့မဟုတ် stderr တွင်ထားရန်သာ လိုအပ်ပြီး စုဆောင်းသူက ၎င်းကို ခွဲထုတ်မည်ဖြစ်သည်။ ဖြစ်နိုင်ချေရှိသော host overload ကိုကာကွယ်ရန် မှတ်တမ်းများကို အတုံးလိုက်ဖြင့် စုဆောင်းထားပါသည်။ 

ကွန်တိန်နာများအတွင်းရှိ အလုပ်တာဝန်များ (လုပ်ငန်းစဉ်များ) တစ်လျှောက် မက်ထရစ်များကို စုဆောင်းပါသည်။ အရာအားလုံးကို တဂ်လုပ်ထားသည်- namespace၊ အောက်တွင်၊ အစရှိသည်ဖြင့်၊ ထို့နောက် Prometheus ဖော်မတ်သို့ ပြောင်းပြီး စုစည်းမှု (မှတ်တမ်းများမှလွဲ၍) ရရှိနိုင်မည်ဖြစ်သည်။ ကျွန်ုပ်တို့သည်လည်း မှတ်တမ်းများ၊ မက်ထရစ်များနှင့် ဖြစ်ရပ်များကို Kafka သို့ ပေးပို့ပြီး နောက်ထပ်-

• မှတ်တမ်းများကို Graylog တွင် ရနိုင်သည် (အမြင်ပိုင်းခွဲခြမ်းစိတ်ဖြာမှုအတွက်);
• မှတ်တမ်းများ၊ မက်ထရစ်များ၊ အဖြစ်အပျက်များကို ရေရှည်သိုလှောင်ရန်အတွက် Clickhouse သို့ ပေးပို့ပါသည်။

အားလုံးသည် AWS တွင် အတူတူပင်ဖြစ်ပြီး၊ ကျွန်ုပ်တို့သာလျှင် Graylog ကို Kafka ဖြင့် Cloudwatch ဖြင့် အစားထိုးပါသည်။ မှတ်တမ်းများကို ထိုနေရာသို့ ပို့လိုက်ရာ အားလုံး အဆင်ပြေသွားသည်- ၎င်းတို့ ပိုင်ဆိုင်သည့် အစုအဝေး နှင့် ကွန်တိန်နာ တို့ကို ချက်ချင်း သိသာပါသည်။ Google Stackdriver မှာလည်း အလားတူပါပဲ။ ဆိုလိုသည်မှာ၊ ကျွန်ုပ်တို့၏အစီအစဉ်သည် Kafka နှင့် တိမ်တိုက်တွင် နှစ်မျိုးလုံးလုပ်ဆောင်သည်။ 

pods များပါရှိသော Kubernetes မရှိပါက၊ အစီအစဉ်သည် အနည်းငယ်ပို၍ ရှုပ်ထွေးသော်လည်း ၎င်းသည် တူညီသောမူများကို လုပ်ဆောင်ပါသည်။

တူညီသောလုပ်ငန်းစဉ်များကို ကွန်တိန်နာအတွင်းတွင် လုပ်ဆောင်ပြီး ၎င်းတို့ကို S6 ကို အသုံးပြု၍ ကြိုးကိုင်ထားသည်။ တူညီသောလုပ်ငန်းစဉ်အားလုံးသည် တူညီသောကွန်တိန်နာအတွင်းတွင် လုပ်ဆောင်နေပါသည်။

ရလဒ်အဖြစ်

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

• ရုပ်ပုံများ စုစည်းခြင်းအတွက် စံပြုနည်းလမ်းတစ်ခုကို တီထွင်ခဲ့ပြီး ၎င်းကိုအခြေခံ၍ CI နမူနာပုံစံများကို တီထွင်ခဲ့သည်။
• ဒေတာစုဆောင်းခြင်း အေးဂျင့်များသည် ကျွန်ုပ်တို့၏ Telegraf တိုးချဲ့မှုများဖြစ်သည်။ ကျွန်ုပ်တို့သည် ၎င်းတို့ကို ထုတ်လုပ်မှုတွင် ကောင်းမွန်စွာ စမ်းသပ်ခဲ့သည်။
• pods များတွင် အေးဂျင့်များဖြင့် ကွန်တိန်နာများကို အကောင်အထည်ဖော်ရန် mutation webhook ကို အသုံးပြုပါသည်။ 
• Kubernetes/Rancher ဂေဟစနစ်တွင် ပေါင်းစပ်ထားသည်။
• ကျွန်ုပ်တို့သည် မတူညီသော စုစည်းမှုစနစ်များတွင် တူညီသောကွန်တိန်နာများကို လုပ်ဆောင်နိုင်ပြီး ကျွန်ုပ်တို့မျှော်လင့်ထားသည့်ရလဒ်ကို ရရှိနိုင်ပါသည်။
• လုံးဝပြောင်းလဲနေသော ကွန်တိန်နာစီမံခန့်ခွဲမှုပုံစံကို ဖန်တီးထားသည်။ 

ပူးတွဲရေးသားသူ- Ilya Prudnikov

source: www.habr.com