Kubernetes အစုအဝေးအရင်းအမြစ်များကို စောင့်ကြည့်ခြင်း။

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

အကျိုးအကြောင်းပြောပြမယ်။ Kube Eagleဒါပေမယ့် ဦးစွာဘာကြောင့် စိတ်ရှုပ်ရသလဲ နှင့် အရည်အသွေးမြင့် စောင့်ကြည့်ခြင်း ကို ဘာကြောင့် လိုအပ်ကြောင်း ရှင်းပြပါမယ်။

ဆုံမှတ် 4-50 ၏ အစုအဝေးများစွာကို ငါစီမံခဲ့သည်။ အစုအဝေးတစ်ခုစီတွင် မိုက်ခရိုဝန်ဆောင်မှုနှင့် အပလီကေးရှင်း 200 အထိပါရှိသည်။ ရှိပြီးသား ဟာ့ဒ်ဝဲကို ပိုမိုကောင်းမွန်စွာ အသုံးပြုနိုင်ရန်၊ ဖြန့်ကျက်မှု အများစုကို ပေါက်ကွဲနိုင်သော RAM နှင့် CPU ရင်းမြစ်များဖြင့် ဖွဲ့စည်းထားပါသည်။ ဤနည်းအားဖြင့်၊ pods သည် လိုအပ်ပါက ရရှိနိုင်သောအရင်းအမြစ်များကို ယူနိုင်ပြီး တစ်ချိန်တည်းတွင် ဤ node ပေါ်ရှိ အခြားအပလီကေးရှင်းများကို အနှောင့်အယှက်မဖြစ်စေပါ။ ကောင်းပြီ မဟုတ်ဘူးလား။

အစုအဝေးသည် CPU (8%) နှင့် RAM (40%) အနည်းငယ်သာစားသုံးသော်လည်း၊ node တွင်ရရှိနိုင်သည်ထက် Memory ကိုပိုမိုခွဲဝေချထားရန်ကြိုးစားသောအခါတွင် pods များကိုကြိုတင်ကြိုတင်ပြင်ဆင်ခြင်းဆိုင်ရာပြဿနာများအမြဲကြုံတွေ့နေရသည်။ ထိုအချိန်က ကျွန်ုပ်တို့တွင် Kubernetes အရင်းအမြစ်များကို စောင့်ကြည့်ရန် ဒက်ရှ်ဘုတ်တစ်ခုသာ ရှိခဲ့သည်။ ဒီလိုမျိုး:

cAdvisor တိုင်းထွာချက်များသာရှိသော Grafana ဒက်ရှ်ဘုတ်

ထိုသို့သော panel ဖြင့်၊ memory နှင့် CPU အများအပြားစားသော node များကိုတွေ့ရန်ပြဿနာမဟုတ်ပါ။ ပြဿနာက ဘာအကြောင်းကြောင့်လဲဆိုတာ အဖြေရှာဖို့ပါပဲ။ pods များကို နေရာတကျထားရှိရန်၊ တစ်ဦးသည် pods အားလုံးတွင် အာမခံထားသောအရင်းအမြစ်များကို သတ်မှတ်နိုင်သည် (တောင်းဆိုထားသောအရင်းအမြစ်များ ကန့်သတ်ချက်နှင့်ညီသည်)။ ဒါပေမယ့် ဒါဟာ ဟာ့ဒ်ဝဲရဲ့ ဉာဏ်အကောင်းဆုံး အသုံးပြုမှုတော့ မဟုတ်ပါဘူး။ အစုအဝေးတွင် ရာပေါင်းများစွာသော မမ်မိုရီဂစ်ဂါဘိုက်များစွာ ရှိပြီး အချို့သော နုတ်များ ငတ်နေချိန်တွင် အချို့မှာ အရန်သိုလှောင်မှုတွင် 4-10 GB ကျန်ရှိသည်။

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

အခမဲ့ရင်းမြစ်များနှင့် တောင်းဆိုမှုအခြေအနေများကို ကျေနပ်စေသော ကုဒ်နံပါတ်ကို pod အတွက် ရွေးချယ်ထားသည်။ node များရှိ တောင်းဆိုထားသော အရင်းအမြစ်များသည် အမှန်တကယ်အသုံးပြုမှုနှင့် မကိုက်ညီကြောင်း တွေ့ရှိခဲ့ရပြီး ၎င်းသည် Kube Eagle နှင့် ၎င်း၏အရင်းအမြစ်စောင့်ကြည့်ရေးစွမ်းရည်များကို ကယ်တင်နိုင်ခဲ့သည်။

ကျွန်ုပ်တွင်သာ စောင့်ကြည့်သော Kubernetes အစုအဝေးအားလုံးနီးပါးရှိသည်။ Node တင်ပို့သူ и Kube ပြည်နယ် မက်ထရစ်များ. Node Exporter သည် I/O နှင့် disk၊ CPU နှင့် RAM အသုံးပြုမှုဆိုင်ရာ စာရင်းဇယားများကို ပေးဆောင်ပြီး Kube State Metrics သည် တောင်းဆိုမှုများနှင့် CPU နှင့် memory resource ကန့်သတ်ချက်များကဲ့သို့သော Kubernetes အရာဝတ္ထုမက်ထရစ်များကို ပြသထားသည်။

ကျွန်ုပ်တို့သည် အသုံးပြုမှုမက်ထရစ်များကို Grafana ရှိ တောင်းဆိုချက်များနှင့် ကန့်သတ်မက်ထရစ်များနှင့် ပေါင်းစပ်ရန် လိုအပ်ပြီး ပြဿနာနှင့်ပတ်သက်သည့် အချက်အလက်အားလုံးကို ကျွန်ုပ်တို့ ရရှိမည်ဖြစ်သည်။ ၎င်းသည် ရိုးရှင်းသည်ဟု ထင်ရသော်လည်း ကိရိယာနှစ်ခုသည် အမှန်တကယ်တွင် အညွှန်းများကို ကွဲပြားစွာ အမည်ပေးကြပြီး အချို့သော မက်တာဒေတာ အညွှန်းများ လုံးဝမရှိပါ။ Kube Eagle သည် အရာအားလုံးကို ကိုယ်တိုင်လုပ်ဆောင်ပြီး အကန့်သည် ဤကဲ့သို့ ဖြစ်သည်-

Kube Eagle ဒက်ရှ်ဘုတ်

ကျွန်ုပ်တို့သည် အရင်းအမြစ်များဖြင့် ပြဿနာများစွာကို ဖြေရှင်းနိုင်ခဲ့ပြီး စက်ပစ္စည်းများကို ချွေတာနိုင်သည်-

1. အချို့သော developer များသည် microservices အရင်းအမြစ်များမည်မျှလိုအပ်သည်ကို မသိခဲ့ပါ (သို့မဟုတ် ရိုးရှင်းစွာအနှောက်အယှက်မရှိ)။ အရင်းအမြစ်များအတွက် မှားယွင်းသော တောင်းဆိုမှုများကို ရှာဖွေရန် ကျွန်ုပ်တို့အတွက် နည်းလမ်းမရှိပါ - ၎င်းအတွက် စားသုံးမှုအပြင် တောင်းဆိုမှုများနှင့် ကန့်သတ်ချက်များကို သိရှိရန် လိုအပ်ပါသည်။ ယခု ၎င်းတို့သည် Prometheus မက်ထရစ်များကိုမြင်ရပြီး အမှန်တကယ်အသုံးပြုမှုကို စောင့်ကြည့်ကာ တောင်းဆိုချက်များနှင့် ကန့်သတ်ချက်များကို ချိန်ညှိပါ။
2. JVM အပလီကေးရှင်းများသည် ၎င်းတို့ကိုင်တွယ်နိုင်သလောက် RAM ကို ယူသည်။ အမှိုက်စုဆောင်းသူသည် 75% ကျော်အသုံးပြုသောအခါတွင်သာ မှတ်ဉာဏ်ကို ထုတ်လွှတ်သည်။ ဝန်ဆောင်မှုအများစုတွင် ပေါက်ကွဲနိုင်သောမှတ်ဉာဏ်ရှိသောကြောင့်၊ ၎င်းကို JVM မှ အမြဲတမ်းသိမ်းပိုက်ထားသည်။ ထို့ကြောင့်၊ ဤ Java ဝန်ဆောင်မှုအားလုံးသည် မျှော်လင့်ထားသည်ထက် RAM များစွာပိုစားနေပါသည်။
3. အချို့သော အပလီကေးရှင်းများက မန်မိုရီကို အလွန်အကျွံ တောင်းဆိုကြပြီး Kubernetes အစီအစဉ်ဆွဲသူသည် ဤ node များကို အခြားအပလီကေးရှင်းများသို့ မပေးဘဲ၊ အမှန်မှာ ၎င်းတို့သည် အခြား node များထက် ပိုလွတ်လပ်သော်လည်း၊ ဆော့ဖ်ဝဲအင်ဂျင်နီယာတစ်ဦးသည် တောင်းဆိုချက်တွင် ဂဏန်းအပိုတစ်ခုကို မတော်တဆထည့်လိုက်ပြီး RAM အပိုင်း- 20 အစား 2 GB ကို ဖမ်းယူလိုက်ပါသည်။ မည်သူမျှ သတိမထားမိပါ။ အပလီကေးရှင်းတွင် ပုံတူ 3 ခုပါရှိသောကြောင့် node 3 ခုအထိထိခိုက်ခဲ့သည်။
4. ကျွန်ုပ်တို့သည် အရင်းအမြစ်ကန့်သတ်ချက်များ၊ မှန်ကန်သောတောင်းဆိုမှုများဖြင့် အချိန်ဇယားဆွဲထားသော pod များကို မိတ်ဆက်ပေးခဲ့ပြီး node အားလုံးတွင် ဟာ့ဒ်ဝဲအသုံးပြုမှု၏ စံပြလက်ကျန်တစ်ခုကို ရရှိခဲ့ပါသည်။ node နှစ်ခုလုံးကို လုံးလုံးပိတ်ထားနိုင်သည်။ ပြီးတော့ ကျွန်တော်တို့မှာ စက်တွေ မှားနေတယ် (CPU ကို ဦးတည်တယ်၊ Memory oriented မဟုတ်ဘူး)။ ကျွန်ုပ်တို့သည် အမျိုးအစားကိုပြောင်းပြီး နောက်ထပ် node အများအပြားကို ဖျက်လိုက်ပါသည်။

ရလဒ်များကို

အစုအဝေးတွင် ပေါက်ကွဲနိုင်သော အရင်းအမြစ်များဖြင့် သင်သည် ရရှိနိုင်သော ဟာ့ဒ်ဝဲကို ပိုမိုထိရောက်စွာ အသုံးပြုသော်လည်း Kubernetes အချိန်ဇယားဆွဲသူသည် အရင်းအမြစ်များအတွက် တောင်းဆိုမှုများအပေါ် အခြေခံ၍ pods များကို အချိန်ဇယားဆွဲပေးကာ ၎င်းသည် ရှုပ်ထွေးသည်။ ငှက်နှစ်ကောင်ကို ကျောက်တစ်လုံးတည်းဖြင့်သတ်ရန်- ပြဿနာများကို ရှောင်ရှားရန်နှင့် အရင်းအမြစ်များကို အပြည့်အဝအသုံးချရန်၊ ကောင်းစွာစောင့်ကြည့်ရန် လိုအပ်သည်။ အဲဒါကြောင့် အသုံးဝင်ပါလိမ့်မယ်။ Kube Eagle (Prometheus တင်ပို့သူနှင့် Grafana ဒက်ရှ်ဘုတ်)။

source: www.habr.com