Kubernetes တွင် အော်တိုစကေးချဲ့ခြင်းနှင့် အရင်းအမြစ်စီမံခန့်ခွဲမှု (ပြန်လည်သုံးသပ်ခြင်းနှင့် ဗီဒီယိုအစီရင်ခံစာ)

ဧပြီ ၈ ရက် ဆွေးနွေးပွဲ လုပ်ကြံမှု 2019"DevOps" ကဏ္ဍ၏ တစ်စိတ်တစ်ပိုင်းအနေဖြင့် " Kubernetes ရှိ အော်တိုစကေးချခြင်းနှင့် အရင်းအမြစ်စီမံခန့်ခွဲမှု" အစီရင်ခံစာကို ပေးအပ်ခဲ့သည်။ သင့်အပလီကေးရှင်းများ မြင့်မားစွာရရှိနိုင်မှုသေချာစေရန်နှင့် အမြင့်ဆုံးစွမ်းဆောင်ရည်သေချာစေရန် K8s ကို သင်မည်သို့အသုံးပြုရမည်အကြောင်း ဆွေးနွေးထားသည်။

အစဉ်အလာအားဖြင့် တင်ဆက်ရတာ ကျေနပ်ပါတယ်။ အစီရင်ခံစာဗီဒီယို (၄၄ မိနစ်၊ ဆောင်းပါးထက် များစွာပို၍ အချက်အလက်များ) နှင့် စာသားပုံစံတွင် အဓိကအကျဉ်းချုပ်။ သွား!

အစီရင်ခံစာ၏ ခေါင်းစဉ်ကို စကားလုံးဖြင့် ခွဲခြမ်းစိတ်ဖြာပြီး အဆုံးမှ စတင်ကြပါစို့။

Kubernetes

ကျွန်ုပ်တို့၏အိမ်ရှင်တွင် Docker ကွန်တိန်နာများရှိသည်ဆိုပါစို့။ ဘာအတွက်လဲ? ရိုးရှင်းပြီး ကောင်းမွန်သော ဖြန့်ကျက်မှုကို ခွင့်ပြုပေးသည့် ထပ်တလဲလဲဖြစ်နိုင်မှုနှင့် သီးခြားခွဲထားမှုကို သေချာစေရန်၊ CI/CD။ ကျွန်ုပ်တို့တွင် ကွန်တိန်နာများပါသော ယာဉ်များစွာရှိသည်။

ဤကိစ္စတွင် Kubernetes ကဘာတွေပေးသလဲ။

1. ကျွန်ုပ်တို့သည် ဤစက်များအကြောင်း တွေးမနေတော့ဘဲ “cloud” နှင့် စတင်အလုပ်လုပ်သည် ကွန်တိန်နာအစုအဝေး သို့မဟုတ် အစေ့များ (ကွန်တိန်နာအုပ်စုများ)။
2. ထို့အပြင်၊ ကျွန်ုပ်တို့သည် တစ်ဦးချင်း pods များအကြောင်းကိုပင် မစဉ်းစားဘဲ ပိုမိုစီမံခန့်ခွဲပါ။оပိုကြီးသောအဖွဲ့များ။ အဲလို အဆင့်မြင့် primitives အလုပ်တာဝန်တစ်ခုအား လုပ်ဆောင်ရန်အတွက် ပုံစံပလိတ်တစ်ခုရှိကြောင်း ကျွန်ုပ်တို့အား ပြောခွင့်ပြုပါ၊ ၎င်းကို လုပ်ဆောင်ရန် လိုအပ်သော အကြိမ်အရေအတွက်များဖြစ်သည်။ ကျွန်ုပ်တို့သည် နမူနာပုံစံကို နောက်ပိုင်းတွင် ပြောင်းလဲပါက၊ ဖြစ်ရပ်များအားလုံး ပြောင်းလဲသွားပါမည်။
3. နှင့် ကြေငြာ API တိကျသော command များကို ဆက်တိုက်လုပ်ဆောင်မည့်အစား Kubernetes မှ ဖန်တီးထားသည့် "ကမ္ဘာ၏ဖွဲ့စည်းပုံ" (YAML) ကို ဖော်ပြပါသည်။ တစ်ဖန်- ဖော်ပြချက် ပြောင်းလဲသောအခါ ၎င်း၏ လက်တွေ့ပြသမှုသည်လည်း ပြောင်းလဲသွားမည်ဖြစ်သည်။

အရင်းအမြစ်စီမံခန့်ခွဲမှု

စီပီယူ

ဆာဗာပေါ်တွင် nginx၊ php-fpm နှင့် mysql ကို run ကြပါစို့။ ဤဝန်ဆောင်မှုများသည် အမှန်တကယ်လုပ်ဆောင်နေသည့် လုပ်ငန်းစဉ်များ ပိုမိုများပြားလာမည်ဖြစ်ပြီး တစ်ခုစီတွင် ကွန်ပျူတာအရင်းအမြစ်များ လိုအပ်သည်-

(ဆလိုက်ပေါ်ရှိ ဂဏန်းများသည် "ကြက်တူရွေးများ" ဖြစ်သည်၊ တွက်ချက်မှုစွမ်းအားအတွက် လုပ်ငန်းစဉ်တစ်ခုစီ၏ စိတ္တဇလိုအပ်မှု)

၎င်းနှင့်ပိုမိုလွယ်ကူစေရန်အတွက်၊ လုပ်ငန်းစဉ်များကို အုပ်စုများအဖြစ် ပေါင်းစည်းရန် ယုတ္တိတန်ပါသည် (ဥပမာ၊ nginx လုပ်ငန်းစဉ်အားလုံးကို အုပ်စုတစ်စု “nginx” သို့) ပေါင်းစပ်ရန် ယုတ္တိတန်ပါသည်။ ၎င်းကိုပြုလုပ်ရန် ရိုးရှင်းပြီး သိသာထင်ရှားသောနည်းလမ်းမှာ အုပ်စုတစ်ခုစီကို ကွန်တိန်နာတစ်ခုထဲတွင် ထည့်ထားခြင်းဖြစ်သည်။

ရှေ့ဆက်ရန်၊ ကွန်တိန်နာတစ်ခု (Linux တွင်) ဟူသည်ကို သင်မှတ်မိရန်လိုသည်။ ကြာမြင့်စွာကတည်းက အကောင်အထည်ဖော်ခဲ့သော kernel ရှိ အဓိကအင်္ဂါရပ်သုံးခုကြောင့် ၎င်းတို့၏အသွင်အပြင်ကို ဖန်တီးနိုင်သည်- စွမ်းရည်, အမည်နေရာခြား и အုပ်စုများ. ထို့အပြင် Docker ကဲ့သို့ အဆင်ပြေသော “အခွံများ” အပါအဝင် အခြားသော နည်းပညာများဖြင့် ပိုမိုဖွံ့ဖြိုးတိုးတက်မှုကို ပံ့ပိုးပေးခဲ့ပါသည်။

အစီရင်ခံစာ၏ စပ်လျဉ်း၍ ကျွန်ုပ်တို့သာ စိတ်ဝင်စားပါသည်။ အုပ်စုများအဘယ်ကြောင့်ဆိုသော် ထိန်းချုပ်မှုအဖွဲ့များသည် အရင်းအမြစ်စီမံခန့်ခွဲမှုကို အကောင်အထည်ဖော်သည့် containers (Docker, etc.) ၏ လုပ်ဆောင်နိုင်စွမ်း၏ အစိတ်အပိုင်းဖြစ်သောကြောင့် ဖြစ်သည်။ ကျွန်ုပ်တို့အလိုရှိသည့်အတိုင်း အုပ်စုများအဖြစ် ပေါင်းစပ်ထားသော လုပ်ငန်းစဉ်များသည် ထိန်းချုပ်မှုအဖွဲ့များဖြစ်သည်။

ဤလုပ်ငန်းစဉ်များအတွက် CPU လိုအပ်ချက်များကို ပြန်သွားကြစို့၊ ယခု လုပ်ငန်းစဉ်အုပ်စုများအတွက်-

(ကိန်းဂဏန်းများအားလုံးသည် အရင်းအမြစ်များ လိုအပ်ခြင်း၏ စိတ္တဇအသုံးအနှုန်းတစ်ခုဖြစ်ကြောင်း ထပ်လောင်းပြောပါသည်။)

တစ်ချိန်တည်းမှာပင်၊ CPU ကိုယ်တိုင်တွင် သတ်မှတ်ထားသော အရင်းအမြစ်တစ်ခုရှိသည်။ (ဥပမာ 1000)လူတိုင်း ချို့တဲ့နိုင်သည် (အုပ်စုအားလုံး၏ လိုအပ်ချက်ပေါင်းလဒ်သည် 150+850+460=1460)။ ဒီကိစ္စမှာ ဘာဖြစ်သွားမလဲ။

kernel သည် အရင်းအမြစ်များကို စတင်ဖြန့်ဝေပြီး အုပ်စုတစ်ခုစီအား တူညီသောအရင်းအမြစ်ပမာဏကို ပေးခြင်းဖြင့် ၎င်းကို "မျှမျှတတ" လုပ်ဆောင်သည်။ သို့သော် ပထမအခြေအနေတွင် လိုအပ်သည်ထက် (333>150) ပိုများသည် ထို့ကြောင့် ပိုလျှံသော (333-150=183) သည် အခြားကွန်တိန်နာနှစ်ခုကြားတွင်လည်း အညီအမျှ ခွဲဝေပေးသည့် အရန်ငွေအဖြစ် ကျန်ရှိနေပါသည်။

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

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

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

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

ဤချဉ်းကပ်မှုကို hard quotas ဟုခေါ်သည်။ (ခက်ခဲ ကန့်သတ်ချက်). ရိုးရိုးရှင်းရှင်းပဲ မှတ်ရအောင် ကန့်သတ်ချက်. သို့သော်လည်း၊ သင်သည် ကွန်တိန်နာများအားလုံးသို့ ကန့်သတ်ချက်များကို ဖြန့်ဝေပါက ပြဿနာတစ်ခု ဖြစ်ပေါ်လာသည်- mysql သည် လမ်းတစ်လျှောက်တွင် မောင်းနှင်နေပြီး တစ်ချိန်ချိန်တွင် CPU လိုအပ်မှု ပြီးဆုံးသွားသော်လည်း အခြားသော လုပ်ငန်းစဉ်အားလုံးကို CPU သည်အထိ စောင့်ခိုင်းရသည်။ ဘာမှမလုပ်ဘူး။.

Linux kernel နှင့် CPU နှင့်၎င်း၏အပြန်အလှန်အကျိုးသက်ရောက်မှုသို့ပြန်ကြပါစို့ - ခြုံငုံရုပ်ပုံသည်အောက်ပါအတိုင်းဖြစ်သည်-

cgroup တွင် ဆက်တင်နှစ်ခု ပါရှိသည် - အခြေခံအားဖြင့် ၎င်းတို့သည် သင့်အား ဆုံးဖြတ်ခွင့်ပြုသည့် ရိုးရှင်းသော "လှည့်ကွက်" နှစ်ခုဖြစ်သည်-

1. container (တောင်းဆိုမှုများ) အတွက်အလေးချိန် ရှယ်ယာ;
2. ကွန်တိန်နာတာဝန်များ (ကန့်သတ်ချက်များ) တွင်အလုပ်လုပ်ခြင်းအတွက်စုစုပေါင်း CPU အချိန်၏ရာခိုင်နှုန်း သတ်မှတ်ဝေပုံ.

CPU ကို ဘယ်လိုတိုင်းတာမလဲ။

နည်းလမ်းအမျိုးမျိုးရှိပါသည်-

1. အဘယျသို့ ကြက်တူရွေးဘယ်သူကမှ မသိပါဘူး - အချိန်တိုင်း ညှိနှိုင်းဖို့ လိုပါတယ်။
2. စိတ်ဝင်စားမှု ပိုမိုရှင်းလင်းသော်လည်း ဆွေမျိုး- 50 cores ရှိသော ဆာဗာ၏ 4% နှင့် 20 cores တို့သည် လုံးဝကွဲပြားသောအရာများဖြစ်သည်။
3. ဖော်ပြပြီးသားတွေကို အသုံးပြုနိုင်ပါတယ်။ အလေးLinux သည် သိသော်လည်း ၎င်းတို့သည် ဆွေမျိုးများဖြစ်သည်။
4. အလုံလောက်ဆုံးရွေးချယ်မှုမှာ ကွန်ပြူတာအရင်းအမြစ်များကို တိုင်းတာရန်ဖြစ်သည်။ စက္ကန့်. အဲဒါတွေ။ ပရိုဆက်ဆာအချိန်၏ စက္ကန့်ပိုင်းအတွင်း အစစ်အမှန်အချိန်၏စက္ကန့်များနှင့် ဆက်စပ်မှု- ပရိုဆက်ဆာအချိန်၏ 1 စက္ကန့်ကို အစစ်အမှန်တစ်စက္ကန့်လျှင် ပေးသည် - ၎င်းသည် CPU core တစ်ခုလုံးဖြစ်သည်။

စကားပြောရ ပိုလွယ်ကူစေရန်၊ သူတို့သည် တိုက်ရိုက်တိုင်းတာရန် စတင်ခဲ့သည်။ စေ့များအဓိပ္ပါယ်မှာ ၎င်းတို့သည် တူညီသော CPU အချိန် အစစ်အမှန်နှင့် သက်ဆိုင်သည်။ Linux သည် အလေးချိန်များကို နားလည်သော်လည်း CPU အချိန်/core များ သိပ်မရှိသောကြောင့်၊ တစ်ခုမှ အခြားသို့ ဘာသာပြန်ရန် ယန္တရားတစ်ခု လိုအပ်ပါသည်။

၎င်းတို့အား ခွဲဝေပေးထားသည့် cores များ၏ သက်ဆိုင်ရာ အစိတ်အပိုင်းများ (3၊ 500 နှင့် 1000) သို့ အလွယ်တကူ ပြောင်းနိုင်သော အလေးများ (1500၊ 0,5 နှင့် 1) ရှိသည့် ပေါ့ဒ်သုံးခုကို ပေးမည့် ရိုးရှင်းသော ဥပမာကို သုံးသပ်ကြည့်ကြပါစို့။

အကယ်၍ သင်သည် cores (6) နှစ်ဆများသော ဒုတိယဆာဗာတစ်ခုကိုယူ၍ တူညီသော pods များကိုထားရှိပါက၊ cores ဖြန့်ဖြူးမှုကို 2 (1၊ 2 နှင့် 3 အသီးသီး) ဖြင့် မြှောက်ခြင်းဖြင့် အလွယ်တကူတွက်ချက်နိုင်ပါသည်။ သို့သော် အဆင်ပြေစေရန်အတွက် အလေးချိန် 3000 ဖြစ်မည့် ဤဆာဗာတွင် စတုတ္ထ pod တစ်ခုပေါ်လာသောအခါတွင် အရေးကြီးသောအခိုက်အတန့်တစ်ခု ဖြစ်ပေါ်ပါသည်။ ၎င်းသည် CPU ရင်းမြစ်များ၏ တစ်စိတ်တစ်ပိုင်း (cores တစ်ဝက်) ကို ယူဆောင်သွားကာ ကျန် pods များအတွက် ၎င်းတို့ကို ပြန်လည်တွက်ချက်ထားသည် (တစ်ဝက်ခွဲထားသည်)။

Kubernetes နှင့် CPU အရင်းအမြစ်များ

Kubernetes တွင် CPU အရင်းအမြစ်များကို များသောအားဖြင့် တိုင်းတာသည်။ milliadrax, i.e. 0,001 Core များကို အခြေခံအလေးချိန်အဖြစ် ယူသည်။ (Linux/cgroups ဝေါဟာရတွင် တူညီသောအရာကို CPU share ဟုခေါ်သည်၊ သို့သော် ပို၍တိကျသည်မှာ၊ 1000 millicores = 1024 CPU shares။) K8s သည် pods များအားလုံး၏အလေးချိန်ပေါင်းစုအတွက် CPU အရင်းအမြစ်များထက်ဆာဗာတွင် pods များပိုမိုမထားရှိကြောင်းသေချာစေသည်။

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

ဖြစ်ရင် ဘာဖြစ်မလဲ။ မဟုတ် တောင်းဆိုချက်အား သတ်မှတ်ထားသည် (ဆိုလိုသည်မှာ pod တွင် ၎င်းလိုအပ်သော cores အရေအတွက် မပါရှိပါ)။ Kubernetes သည် ယေဘုယျအားဖြင့် အရင်းအမြစ်များကို မည်သို့ရေတွက်သည်ကို အဖြေရှာကြည့်ကြပါစို့။

ပေါ့ဒ်တစ်ခုအတွက် သင်သည် တောင်းဆိုမှုများ (CFS အစီအစဉ်ဆွဲသူ) နှင့် ကန့်သတ်ချက်များ (မီးပွိုင့်ကို မှတ်မိပါသလား။)

• ၎င်းတို့ကို တန်းတူသတ်မှတ်ထားပါက pod ကို QoS အတန်းအစား သတ်မှတ်ပေးသည်။ အာမခံ. ဤ cores အရေအတွက်ကို အမြဲရရှိနိုင်ကြောင်း အာမခံပါသည်။
• တောင်းဆိုမှုကန့်သတ်ချက်ထက်နည်းပါက - QoS အတန်းအစား ပေါက်ကွဲနိုင်သော. အဲဒါတွေ။ ဥပမာအားဖြင့်၊ ကျွန်ုပ်တို့သည် pod တစ်ခုအား 1 core ကို အမြဲတမ်းအသုံးပြုရန် မျှော်လင့်ထားသော်လည်း ဤတန်ဖိုးသည် ၎င်းအတွက် ကန့်သတ်ချက်မဟုတ်ပါ- တခါတလေ pod သည် ပိုမိုအသုံးပြုနိုင်သည် (ဆာဗာတွင် ၎င်းအတွက် အခမဲ့အရင်းအမြစ်များရှိနေသောအခါ)။
• QoS အတန်းလည်းရှိပါတယ်။ အကောင်းဆုံးအားထုတ်မှု - ၎င်းတွင် တောင်းဆိုမှုအား အတိအကျ မဖော်ပြထားသော အလွန် pods များ ပါဝင်သည်။ အရင်းအမြစ်များကို နောက်ဆုံးထား၍ ပေးအပ်သည်။

မှတ်ဉာဏ်

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

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

၎င်းသည် ကျွန်ုပ်တို့နှင့် အမြဲမကိုက်ညီသောကြောင့် မည်သည့်လုပ်ငန်းစဉ်များသည် ကျွန်ုပ်တို့အတွက် အရေးကြီးပြီး မသတ်သင့်သည်ကို ထိန်းညှိရန် ဖြစ်နိုင်သည်။ ဒါကိုလုပ်ဖို့၊ parameter ကိုသုံးပါ။ oom_score_adj.

CPU ၏ QoS အတန်းများသို့ ပြန်သွားပြီး pods အတွက် မှတ်ဉာဏ်သုံးစွဲမှု ဦးစားပေးများကို ဆုံးဖြတ်ပေးသည့် oom_score_adj တန်ဖိုးများနှင့် နှိုင်းယှဉ်မှုတစ်ခုကို ရေးဆွဲကြပါစို့။

• pod တစ်ခုအတွက် အနိမ့်ဆုံး oom_score_adj တန်ဖိုး - -998 - ဆိုလိုသည်မှာ ထို pod ကို နောက်ဆုံးသတ်သင့်သည်၊ အာမခံ.
• အမြင့်ဆုံး - 1000 - အကောင်းဆုံးအားထုတ်မှုဒီလိုမျိုး အစေ့တွေကို အရင်သတ်ပစ်တယ်။
• ကျန်တန်ဖိုးများကို တွက်ချက်ရန် (ပေါက်ကွဲနိုင်သော) ဖော်မြူလာတစ်ခုရှိပါတယ်၊ အရင်းအနှီးပိုတောင်းလေလေ အသတ်ခံရနိုင်ခြေနည်းလေဆိုတဲ့ အချက်ရဲ့ အနှစ်သာရက ပြုတ်ကျသွားပါတယ်။

ဒုတိယ "လှည့်ကွက်" - limit_in_bytes - ကန့်သတ်ချက်များအတွက်။ ၎င်းနှင့်အတူ၊ အရာအားလုံးပိုမိုရိုးရှင်းသည်- ကျွန်ုပ်တို့သည် ထုတ်လွှတ်သော မန်မိုရီအများဆုံးပမာဏကို သတ်မှတ်ပေးပြီး ဤနေရာတွင် (CPU နှင့်မတူဘဲ) ၎င်းအား တိုင်းတာနည်း (memory) ကို မေးခွန်းထုတ်စရာမရှိပါ။

စုစုပေါင်း

Kubernetes ရှိ pod တစ်ခုစီကို ပေးထားသည်။ requests и limits - CPU နှင့် memory အတွက် parameters နှစ်ခုလုံး-

1. တောင်းဆိုမှုများအပေါ်အခြေခံ၍ Kubernetes အစီအစဉ်ဆွဲသူသည် ဆာဗာများကြားတွင် pods များကို ဖြန့်ဝေပေးသည်။
2. ကန့်သတ်ချက်များအားလုံးကို အခြေခံ၍ pod ၏ QoS အတန်းအစားကို ဆုံးဖြတ်သည်။
3. CPU တောင်းဆိုမှုများအပေါ် အခြေခံ၍ နှိုင်းရအလေးချိန်များကို တွက်ချက်ပါသည်။
4. CFS အချိန်ဇယားကို CPU တောင်းဆိုမှုများအပေါ် အခြေခံ၍ ပြင်ဆင်သတ်မှတ်ထားသည်။
5. OOM လူသတ်သမားသည် မှတ်ဉာဏ်တောင်းဆိုမှုများအပေါ် အခြေခံ၍ ပြင်ဆင်သတ်မှတ်ထားသည်။
6. CPU ကန့်သတ်ချက်များကို အခြေခံ၍ "မီးပွိုင့်" ကို ပြင်ဆင်သတ်မှတ်ထားသည်။
7. မမ်မိုရီကန့်သတ်ချက်များအပေါ် အခြေခံ၍ cgroup အတွက် ကန့်သတ်ချက်တစ်ခုကို စီစဉ်သတ်မှတ်ထားသည်။

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

အော်တိုစကေးချဲ့ခြင်း။

K8s cluster-autoscaler

အစုအဝေးတစ်ခုလုံးကို သိမ်းပိုက်ထားပြီးဖြစ်ပြီး ပေါ့ဒ်အသစ်တစ်ခုကို ဖန်တီးရန် လိုအပ်သည်ဟု စိတ်ကူးကြည့်ကြပါစို့။ ဘူးသည် မပေါ်နိုင်သော်လည်း အခြေအနေတွင် ချိတ်ထားသည်။ လာမည့်. ၎င်းကို ပေါ်လာစေရန်၊ ကျွန်ုပ်တို့အတွက် ဆာဗာအသစ်တစ်ခုကို အစုအဝေးသို့ ချိတ်ဆက်နိုင်သည် သို့မဟုတ် ... ကျွန်ုပ်တို့အတွက် လုပ်ဆောင်ပေးမည့် cluster-autoscaler ကို ထည့်သွင်းနိုင်သည်- cloud ဝန်ဆောင်မှုပေးသူထံမှ virtual machine တစ်ခုကို (API တောင်းဆိုမှုတစ်ခုအသုံးပြု၍) မှာယူပြီး အစုအဝေးသို့ ချိတ်ဆက်ပါ။ ပြီးမှ အိုးကို ထည့်မယ်။

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

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

Deployment ပါရှိသော ဆာဗာ 3 ခု၏ အစုအဝေးတစ်ခုကို သုံးသပ်ကြည့်ပါ။ ၎င်းတွင် pod 6 ခု ရှိသည်- ယခု ဆာဗာတစ်ခုစီအတွက် 2 ခုရှိသည်။ အကြောင်းတစ်ခုခုကြောင့် ဆာဗာများထဲမှ တစ်ခုကို ပိတ်ချင်ပါသည်။ ဒီလိုလုပ်ဖို့ကျွန်ုပ်တို့ command ကိုအသုံးပြုပါလိမ့်မယ်။ kubectl drain၊

• ဤဆာဗာသို့ pods အသစ်များပေးပို့ခြင်းကိုတားမြစ်လိမ့်မည်။
• ဆာဗာပေါ်တွင် ရှိပြီးသား pods များကို ဖျက်ပါမည်။

Kubernetes သည် pods အရေအတွက် (6) ကို ထိန်းသိမ်းထားရန် တာဝန်ရှိသောကြောင့် ၎င်းသည် ရိုးရှင်းပါသည်။ ပြန်လည်ဖန်တီးပါမည်။ ၎င်းတို့ကို အခြား node များပေါ်တွင် ပိတ်ထားသော်လည်း၊ ၎င်းသည် pods အသစ်များကို hosting အတွက် မရရှိနိုင်ဟု အမှတ်အသားပြုထားပြီးဖြစ်သောကြောင့် ၎င်းကို disable လုပ်ထားခြင်းဖြစ်သည်။ ၎င်းသည် Kubernetes အတွက် အခြေခံစက်ပြင်တစ်ခုဖြစ်သည်။

သို့သော် ဤနေရာတွင်လည်း ကွဲလွဲချက်တစ်ခုရှိသည်။ အလားတူအခြေအနေမျိုးတွင်၊ StatefulSet (Deployment အစား) အတွက် လုပ်ဆောင်ချက်များ ကွဲပြားပါမည်။ ယခုကျွန်ုပ်တို့တွင် အကျုံးဝင်သော အက်ပ်တစ်ခု ရှိနှင့်ပြီးဖြစ်သည် - ဥပမာအားဖြင့်၊ ပြဿနာအချို့ရှိနေသည့် MongoDB နှင့် pods သုံးခု (ဒေတာပျက်စီးသွားခြင်း သို့မဟုတ် ပေါ့ဒ်ကိုမှန်ကန်စွာစတင်ခြင်းမှတားဆီးသည့် အခြားအမှားတစ်ခု)။ ကျွန်ုပ်တို့သည် ဆာဗာတစ်ခုအား ပိတ်ရန် ထပ်မံဆုံးဖြတ်ခဲ့သည်။ ဘာဖြစ်မလဲ?

MongoDB နိုင်ခဲ့တယ် quotum တစ်ခု လိုအပ်သောကြောင့် သေဆုံးသည်- ထည့်သွင်းမှု သုံးခုရှိသော အစုအဝေးတစ်ခုအတွက်၊ အနည်းဆုံး နှစ်ခု လုပ်ဆောင်ရပါမည်။ သို့သော်ဤ မဖြစ်ပျက်ဘူး - ကျေးဇူးတင်ပါတယ် PodDisruptionBudget. ဤကန့်သတ်ချက်သည် အလုပ်လုပ်သည့် pods များ၏ အနည်းဆုံးလိုအပ်သော အရေအတွက်ကို ဆုံးဖြတ်သည်။ MongoDB pods များထဲမှ တစ်ခုသည် အလုပ်မလုပ်တော့ကြောင်း သိလျက်နှင့် PodDisruptionBudget ကို MongoDB အတွက် သတ်မှတ်ထားသည်ကို တွေ့လိုက်ရသည် ။ minAvailable: 2၊ Kubernetes သည် သင့်အား pod တစ်ခုကို ဖျက်ရန် ခွင့်ပြုမည်မဟုတ်ပါ။

အောက်ခြေလိုင်း- pods များ၏ ရွေ့လျားမှု (အမှန်အားဖြင့် ပြန်လည်ဖန်တီးမှု) သည် အစုအဝေးကို ထွက်လာသည့်အခါ မှန်ကန်စွာ အလုပ်လုပ်နိုင်ရန်၊ PodDisruptionBudget ကို စီစဉ်သတ်မှတ်ရန် လိုအပ်ပါသည်။

အလျားလိုက် အတိုင်းအတာ

နောက်ထပ် အခြေအနေတစ်ခုကို သုံးသပ်ကြည့်ရအောင်။ Kubernetes တွင် ဖြန့်ကျက်မှုအဖြစ် လုပ်ဆောင်နေသည့် အက်ပ်တစ်ခုရှိသည်။ အသုံးပြုသူအသွားအလာသည် ၎င်း၏ pods များထံရောက်ရှိလာသည် (ဥပမာ၊ ၎င်းတို့တွင် သုံးခုရှိသည်)၊ ၎င်းတို့တွင် အချို့သောညွှန်ပြချက်တစ်ခုကို ကျွန်ုပ်တို့တိုင်းတာသည် (ဆိုပါစို့ CPU load)။ ဝန်ပိုလာသောအခါ၊ ကျွန်ုပ်တို့သည် ၎င်းကို အချိန်ဇယားတစ်ခုပေါ်တွင် မှတ်တမ်းတင်ပြီး တောင်းဆိုမှုများကို ဖြန့်ဝေရန်အတွက် pods အရေအတွက်ကို တိုးမြင့်စေသည်။

ယနေ့ Kubernetes တွင် ၎င်းကို ကိုယ်တိုင်လုပ်ဆောင်ရန် မလိုအပ်ပါ- တိုင်းတာထားသော ဝန်အညွှန်းကိန်းများ၏ တန်ဖိုးများပေါ်မူတည်၍ pods အရေအတွက် အလိုအလျောက် တိုး/လျှော့ ပြုလုပ်ပေးပါသည်။

ဤနေရာတွင် အဓိကမေးခွန်းများမှာ- ဘာကို အတိအကျ တိုင်းတာမလဲ။ и ဘယ်လိုအဓိပ္ပာယ်ဖွင့်မလဲ။ ရရှိသောတန်ဖိုးများ ( pods အရေအတွက်ကိုပြောင်းလဲခြင်းအပေါ်ဆုံးဖြတ်ချက်ချခြင်းအတွက်) ။ သင်အများကြီးတိုင်းတာနိုင်ပါတယ်:

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

ရှိပါတယ် နည်းလမ်းကိုသုံးပါ။ (အသုံးပြုမှု ပြည့်ဝမှုနှင့် အမှားအယွင်းများ) ဟူသော အဓိပ္ပါယ်မှာ အောက်ပါအတိုင်းဖြစ်သည်။ ဥပမာ၊ php-fpm အတိုင်းအတာကို ဘယ်အခြေခံက အဓိပ္ပါယ်ရှိသလဲ။ အလုပ်သမားတွေ ကုန်သွားပြီဆိုတဲ့အချက်ကို အခြေခံပြီးတော့ ဒါက ဒီလိုပါ။ အသုံးချ. အလုပ်သမားတွေ ပြန်ပြီး ချိတ်ဆက်မှုအသစ်တွေကို လက်မခံဘူးဆိုရင် ဒါက ဖြစ်နေပါပြီ။ ရွှဲ. ဤဘောင်နှစ်ခုစလုံးကို တိုင်းတာရမည်ဖြစ်ပြီး တန်ဖိုးများပေါ်မူတည်၍ အတိုင်းအတာကို လုပ်ဆောင်ရမည်ဖြစ်သည်။

အဲဒီအစားတစ်ဦးနိဂုံးပိုင်း၏

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

ဗီဒီယိုများနှင့် ဆလိုက်များ

ဖျော်ဖြေပွဲ ဗီဒီယို (၄၄ မိနစ်)

အစီရင်ခံစာတင်ပြချက်-

PS

ကျွန်ုပ်တို့၏ဘလော့ဂ်ရှိ Kubernetes အကြောင်း အခြားအစီရင်ခံစာများ-

• «Kubernetes ကို တိုးချဲ့ခြင်းနှင့် ဖြည့်စွက်ခြင်း။» (Andrey Polovov; ဧပြီ 8၊ 2019 တွင် Saint HighLoad++);
• «ဒေတာဘေ့စ်များနှင့် Kubernetes» (Dmitry Stolyarov; နိုဝင်ဘာ 8၊ 2018 တွင် HighLoad++);
• «စောင့်ကြည့်ခြင်းနှင့် Kubernetes» (Dmitry Stolyarov; မေလ 28 ရက်၊ 2018 တွင် RootConf);
• «Kubernetes နှင့် GitLab ဖြင့် အကောင်းဆုံး အလေ့အကျင့်များ CI/CD» (Dmitry Stolyarov; နိုဝင်ဘာ 7၊ 2017 တွင် HighLoad++);
• «ပရောဂျက်ငယ်များတွင် Kubernetes နှင့် ကျွန်ုပ်တို့၏အတွေ့အကြုံ» (Dmitry Stolyarov; ဇွန်လ 6၊ 2017 တွင် RootConf).

source: www.habr.com