Kubernetes စွမ်းဆောင်ရည် အကြံပြုချက် ကိုးခု

အားလုံးမင်္ဂလာပါ! ကျွန်ုပ်၏အမည်မှာ Oleg Sidorenkov ဖြစ်ပြီး၊ ကျွန်ုပ်သည် အခြေခံအဆောက်အဦအဖွဲ့၏အကြီးအကဲအဖြစ် DomClick တွင်အလုပ်လုပ်ပါသည်။ ကျွန်ုပ်တို့သည် ထုတ်လုပ်မှုတွင် Kubik ကို သုံးနှစ်ကျော်အသုံးပြုခဲ့ပြီး ယခုအချိန်အတွင်း ၎င်းနှင့်မတူကွဲပြားသော စိတ်ဝင်စားစရာအခိုက်အတန့်များကို တွေ့ကြုံခံစားခဲ့ရသည်။ မှန်ကန်သောချဉ်းကပ်နည်းဖြင့် သင့်အစုအဝေးအတွက် vanilla Kubernetes မှ ပိုမိုစွမ်းဆောင်ရည်ကို ညှစ်ထုတ်နိုင်ပုံကို ယနေ့ ကျွန်ုပ်ပြောပြပါမည်။ အဆင်သင့်ပဲ ငြိမ်သွားလိုက်ပါ။

Kubernetes သည် container orchestration အတွက် အရွယ်တင်နိုင်သော open source စနစ်ဖြစ်သည်ကို သင်ကောင်းစွာသိပါသည်။ ဆာဗာပတ်ဝန်းကျင်တွင် သင့် microservices များ၏ဘဝသံသရာကို စီမံခန့်ခွဲခြင်းဖြင့် မှော်ဆန်သောအလုပ်လုပ်သော ဒွိစုံ 5 ခု။ ထို့အပြင်၊ ၎င်းသည် မတူညီသောလုပ်ငန်းဆောင်တာများအတွက် အများဆုံးစိတ်ကြိုက်ပြုလုပ်ရန်အတွက် Lego ကဲ့သို့ စုစည်းနိုင်သည့် မျှမျှတတပြောင်းလွယ်ပြင်လွယ်ရှိသောကိရိယာတစ်ခုဖြစ်သည်။

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

1. အဖွဲ့နှင့် လျှောက်လွှာအရင်းအမြစ်များကို စောင့်ကြည့်ပါ။

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

resources:
   requests:
     memory: 2Gi
     cpu: 250m
   limits:
     memory: 4Gi
     cpu: 500m

အတွေ့အကြုံအားဖြင့် ကျွန်ုပ်တို့သည် နိဂုံးချုပ်ရပါသည်- သင်သည် ကန့်သတ်ချက်များမှ တောင်းဆိုချက်များကို နှစ်ကြိမ်ထက်ပို၍ မချဲ့သင့်ပါ။ တောင်းဆိုမှုများအပေါ်အခြေခံ၍ အစုအဝေးပမာဏကို တွက်ချက်ပြီး အရင်းအမြစ်များတွင် အပလီကေးရှင်းများကွာခြားချက်ကို ဥပမာအားဖြင့် 5-10 ကြိမ်ပေးမည်ဆိုပါက၊ ၎င်းသည် pods များပြည့်လာပြီး ရုတ်တရက် load ရရှိသောအခါတွင် သင်၏ node တွင် ဘာဖြစ်မည်ကို စိတ်ကူးကြည့်ပါ။ ဘာမှ မကောင်းပါဘူး။ အနိမ့်ဆုံး၊ အဟန့်အတားဖြစ်စေပြီး အမြင့်ဆုံးတွင်၊ သင်သည် လုပ်သားအား နှုတ်ဆက်ပြီး အစေ့များစတင်ရွေ့လျားပြီးနောက် ကျန်ရှိသော node များပေါ်တွင် စက်ဘီးစီးသည့်ဝန်ကို ရရှိမည်ဖြစ်သည်။

နောက်ပြီး အကူအညီနဲ့ limitranges အစတွင်၊ သင်သည် ကွန်တိန်နာအတွက် အရင်းအမြစ်တန်ဖိုးများကို သတ်မှတ်နိုင်သည် - အနိမ့်ဆုံး၊ အများဆုံးနှင့် ပုံသေ-

➜  ~ kubectl describe limitranges --namespace ops
Name:       limit-range
Namespace:  ops
Type        Resource           Min   Max   Default Request  Default Limit  Max Limit/Request Ratio
----        --------           ---   ---   ---------------  -------------  -----------------------
Container   cpu                50m   10    100m             100m           2
Container   ephemeral-storage  12Mi  8Gi   128Mi            4Gi            -
Container   memory             64Mi  40Gi  128Mi            128Mi          2

အဖွဲ့တစ်ဖွဲ့က အစုအဖွဲ့၏ အရင်းအမြစ်အားလုံးကို မသိမ်းပိုက်နိုင်စေရန် namespace အရင်းအမြစ်များကို ကန့်သတ်ရန် မမေ့ပါနှင့်။

➜  ~ kubectl describe resourcequotas --namespace ops
Name:                   resource-quota
Namespace:              ops
Resource                Used          Hard
--------                ----          ----
limits.cpu              77250m        80
limits.memory           124814367488  150Gi
pods                    31            45
requests.cpu            53850m        80
requests.memory         75613234944   150Gi
services                26            50
services.loadbalancers  0             0
services.nodeports      0             0

ဖော်ပြချက်မှ တွေ့မြင်နိုင်သည် resourcequotasops အဖွဲ့သည် အခြားသော 10 cpu ကိုစားသုံးမည့် pods များကို အသုံးချလိုပါက၊ စီစဉ်သူသည် ၎င်းကို ခွင့်မပြုဘဲ အမှားအယွင်းတစ်ခု ပြုလုပ်လိမ့်မည်-

Error creating: pods "nginx-proxy-9967d8d78-nh4fs" is forbidden: exceeded quota: resource-quota, requested: limits.cpu=5,requests.cpu=5, used: limits.cpu=77250m,requests.cpu=53850m, limited: limits.cpu=10,requests.cpu=10

ထိုကဲ့သို့သောပြဿနာကိုဖြေရှင်းရန်, ဥပမာ, ကဲ့သို့သော tool ကိုရေးနိုင်ပါတယ်။ ဤအမိန့်ပေးသည့် အရင်းအမြစ်များကို သိမ်းဆည်း၍ ကတိပြုနိုင်သည်။

2. အကောင်းဆုံးသော ဖိုင်သိုလှောင်မှုကို ရွေးချယ်ပါ။

ဤတွင် ကျွန်ုပ်သည် အမြဲရှိနေသော volumes များနှင့် Kubernetes အလုပ်သမား node များ၏ disk subsystem နှင့်ပတ်သက်သော အကြောင်းအရာကို ပြောချင်ပါသည်။ ထုတ်လုပ်မှုတွင် HDD တွင် "Cube" ကိုမည်သူမျှအသုံးမပြုရန်မျှော်လင့်သော်လည်း တစ်ခါတစ်ရံတွင် ပုံမှန် SSD သည် မလုံလောက်တော့ပါ။ I/O လုပ်ဆောင်ချက်များကြောင့် မှတ်တမ်းများသည် disk ကို သတ်ပစ်သည့် ပြဿနာတစ်ခု ကြုံတွေ့ရပြီး ဖြေရှင်းနည်းများစွာ မရှိပါ-

• စွမ်းဆောင်ရည်မြင့် SSDs ကိုသုံးပါ သို့မဟုတ် NVMe သို့ပြောင်းပါ (သင်ကိုယ်ပိုင်ဟာ့ဒ်ဝဲကို စီမံခန့်ခွဲပါက)။

• သစ်ခုတ်ခြင်းအဆင့်ကို လျှော့ချပါ။

• ဒစ်ကို မုဒိမ်းကျင့်သော pods များ၏ "စမတ်" ဟန်ချက်ညီမှုကို ပြုလုပ်ပါ (podAntiAffinity).

access_logs မှတ်တမ်းကိုဖွင့်ထားသောအခါတွင် nginx-ingress-controller အောက်ရှိ မျက်နှာပြင်သည် ဖြစ်ပျက်နေသည် (~12 logs/sec) ကိုပြသသည်။ ဤအခြေအနေသည် ဤ node ပေါ်ရှိ application အားလုံးကို ပျက်စီးသွားစေနိုင်သည်။

PV အတွက် ဖြစ်ချင်တော့ ကျွန်တော် အကုန်မစမ်းဖူးပါဘူး။ အမျိုးအစားများ အမြဲတမ်း အတွဲများ။ သင့်အတွက် အသင့်တော်ဆုံး ရွေးချယ်မှုကို အသုံးပြုပါ။ သမိုင်းကြောင်းအရ၊ ဝန်ဆောင်မှုများ၏ အစိတ်အပိုင်းအနည်းငယ်သည် RWX အတွဲများ လိုအပ်ပြီး ဤလုပ်ငန်းအတွက် NFS သိုလှောင်မှုကို စတင်အသုံးပြုခဲ့သည်မှာ ကြာမြင့်နေပြီဖြစ်သည်။ စျေးသက်သက်သာသာနဲ့...လုံလောက်ပါတယ်။ ဟုတ်ပါတယ်၊ သူနဲ့ကျွန်တော် ရူးသွပ်တယ် - မင်းကို ကောင်းချီးပေးတယ်၊ ဒါပေမယ့် အဲဒါကို ညှိဖို့ သင်ယူခဲ့ပြီး၊ ငါ့ခေါင်းလည်း မနာတော့ဘူး။ ဖြစ်နိုင်လျှင် S3 အရာဝတ္ထုသိုလှောင်မှုသို့ ရွှေ့ပါ။

3. အကောင်းဆုံးဖြစ်အောင် ပြုလုပ်ထားသော ပုံများကို စုဆောင်းပါ။

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

Optimized ဆိုသည်မှာ ပုံများကို ဆိုလိုသည်-

• အပလီကေးရှင်းတစ်ခုသာပါဝင်ပါ သို့မဟုတ် လုပ်ဆောင်ချက်တစ်ခုသာလုပ်ဆောင်ပါ။

• အရွယ်အစား သေးငယ်သောကြောင့်၊ ကြီးမားသောပုံများကို ကွန်ရက်ပေါ်တွင် ပိုဆိုးစေသောကြောင့်၊

• စက်ရပ်ချိန်တွင် Kubernetes အား အရေးယူဆောင်ရွက်နိုင်ရန် ကျန်းမာရေးနှင့် အဆင်သင့် အဆုံးမှတ်များ ရှိသည်။

• Configuration အမှားများကို ပိုမိုခံနိုင်ရည်ရှိသော ကွန်တိန်နာ-ဖော်ရွေသော လည်ပတ်မှုစနစ်များ (Alpine သို့မဟုတ် CoreOS ကဲ့သို့) ကို အသုံးပြုပါ။

• ပေါင်းစပ်ထားသော အပလီကေးရှင်းများကိုသာ အသုံးပြုနိုင်ပြီး ပါ၀င်သည့်ရင်းမြစ်များကိုသာ အသုံးချနိုင်စေရန် multi-stage တည်ဆောက်မှုများကို အသုံးပြုပါ။

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

1. အစုအဝေးတစ်ခုလုံးတွင် ကွန်ရက်ဝန်ကို လျှော့ချထားသည်။

2. ကွန်တိန်နာ စတင်ချိန်ကို လျှော့ချခြင်း။

3. သင်၏ Docker မှတ်ပုံတင်ခြင်းတစ်ခုလုံး၏ သေးငယ်သောအရွယ်အစား။

4. DNS cache ကိုသုံးပါ။

မြင့်မားသောဝန်များအကြောင်းပြောပါက၊ အစုအဖွဲ့၏ DNS စနစ်အား ချိန်ညှိခြင်းမပြုဘဲ ဘဝသည် အလွန်ဆိုးရွားသည်။ တစ်ချိန်က Kubernetes developer များသည် ၎င်းတို့၏ kube-dns ဖြေရှင်းချက်ကို ထောက်ခံခဲ့ကြသည်။ ၎င်းကို ဤနေရာတွင်လည်း အကောင်အထည်ဖော်ထားသော်လည်း၊ ဤဆော့ဖ်ဝဲကို အထူးချိန်ညှိထားခြင်းမရှိခဲ့ဘဲ လိုအပ်သောစွမ်းဆောင်ရည်ကို မထုတ်လုပ်နိုင်ခဲ့ဘဲ၊ ၎င်းသည် ရိုးရှင်းသောအလုပ်ဖြစ်ပုံရသည်။ ထို့နောက်တွင် ကျွန်ုပ်တို့မှ ပြောင်းလဲခဲ့ပြီး ပူဆွေးခြင်းမရှိသော coredns ပေါ်လာသည်၊ ၎င်းသည် နောက်ပိုင်းတွင် K8s တွင် မူရင်း DNS ဝန်ဆောင်မှုဖြစ်လာခဲ့သည်။ တစ်ချိန်ချိန်တွင်၊ ကျွန်ုပ်တို့သည် DNS စနစ်သို့ 40 rps တိုးလာကာ ဤဖြေရှင်းချက်မှာလည်း မလုံလောက်တော့ပါ။ သို့သော် ကံကောင်းထောက်မစွာဖြင့် Nodelocaldns၊ aka node local cache, aka ထွက်လာခဲ့သည်။ NodeLocal DNSCache.

ဘာကြောင့် ဒါကိုသုံးတာလဲ။ အဓိကအားဖြင့် Linux UDP မှတစ်ဆင့် Conntrack NAT မှတစ်ဆင့် တောင်းဆိုမှုများစွာ ပြုလုပ်သောအခါ Conntrack ဇယားများရှိ entry များအတွက် race condition ကို ဖြစ်ပေါ်စေပြီး NAT မှတစ်ဆင့် traffic အချို့ ဆုံးရှုံးသွားသည့် bug တစ်ခုရှိသည် (Service မှတစ်ဆင့် hop တိုင်းသည် NAT ဖြစ်သည်)။ Nodelocaldns သည် NAT ကို ဖယ်ရှားပြီး upstream DNS အတွက် TCP သို့ ချိတ်ဆက်မှုကို အဆင့်မြှင့်တင်ခြင်းအပြင် upstream DNS သို့ DNS request များကို local caching လုပ်ခြင်း (5-second negative cache တိုတောင်းခြင်းအပါအဝင်) ဖြင့် ဤပြဿနာကို ဖြေရှင်းသည်။

5. အစေ့များကို အလျားလိုက် ဒေါင်လိုက် အလိုအလျောက် ချိန်ညှိပါ။

သင်၏ microservices အားလုံးသည် နှစ်ဆမှ သုံးဆအထိ တိုးလာရန်အတွက် အဆင်သင့်ဖြစ်နေပြီဟု ယုံကြည်စိတ်ချစွာ ပြောနိုင်ပါသလား။ သင့်အပလီကေးရှင်းများထံ အရင်းအမြစ်များကို မည်သို့ခွဲဝေပေးမည်နည်း။ အလုပ်ဝန်ထက်ကျော်လွန်၍ အလုပ်လုပ်သော pods နှစ်ခုကို ထားရှိခြင်းသည် မလိုအပ်တော့သော်လည်း ၎င်းတို့ကို နောက်ကြောင်းပြန်ထားခြင်းဖြင့် ဝန်ဆောင်မှုသို့ အသွားအလာရုတ်တရက် တိုးလာရာမှ အချိန်ရပ်တန့်သွားနိုင်သည့် အန္တရာယ်ရှိသည်။ အစရှိတဲ့ ဝန်ဆောင်မှုများ Horizontal Pod Autoscaler и ဒေါင်လိုက် Pod Autoscaler.

VPA အမှန်တကယ်အသုံးပြုမှုပေါ်မူတည်၍ pod အတွင်းရှိ သင့်ကွန်တိန်နာများ၏ တောင်းဆိုမှုများ/ကန့်သတ်ချက်များကို အလိုအလျောက် မြှင့်တင်နိုင်မည်ဖြစ်သည်။ ဘယ်လိုအသုံးဝင်နိုင်မလဲ။ အကယ်၍ သင့်တွင် အကြောင်းတစ်ခုခုကြောင့် အလျားလိုက် ချိန်ညှိ၍မရသော အကွက်များရှိပါက (လုံးဝ စိတ်မချရသော)၊ ထို့နောက် ၎င်း၏အရင်းအမြစ်များကို VPA သို့ ပြောင်းလဲမှုများ အပ်နှင်းရန် ကြိုးစားနိုင်ပါသည်။ ၎င်း၏အင်္ဂါရပ်သည် မက်ထရစ်ဆာဗာမှ သမိုင်းဝင်နှင့် လက်ရှိဒေတာအပေါ်အခြေခံသည့် အကြံပြုချက်စနစ်ဖြစ်သောကြောင့် တောင်းဆိုမှုများ/ကန့်သတ်ချက်များကို အလိုအလျောက်မပြောင်းလဲလိုပါက၊ သင်သည် သင်၏ကွန်တိန်နာအတွက် အကြံပြုထားသောရင်းမြစ်များကို ရိုးရှင်းစွာစောင့်ကြည့်နိုင်ပြီး CPU ကို သိမ်းဆည်းရန်အတွက် ဆက်တင်များကို အကောင်းဆုံးဖြစ်အောင် ပြုလုပ်နိုင်သည်။ အစုအဝေးတွင်မှတ်ဉာဏ်။

ပုံအား https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231 မှ ရိုက်ယူထားသည်

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

ဥပမာအားဖြင့်၊ ဤသည်မှာ ပုံမှန် pod ဆက်တင်များဖြစ်သည်-

resources:
   requests:
     memory: 250Mi
     cpu: 200m
   limits:
     memory: 500Mi
     cpu: 350m

သင့်အပလီကေးရှင်းသည် ကောင်းစွာလည်ပတ်ရန် 300m CPU နှင့် 500Mi လိုအပ်ကြောင်း အကြံပြုချက်အင်ဂျင်က ဆုံးဖြတ်သည်။ အောက်ပါဆက်တင်များကို သင်ရရှိပါမည်-

resources:
   requests:
     memory: 500Mi
     cpu: 300m
   limits:
     memory: 1000Mi
     cpu: 525m

အထက်တွင်ဖော်ပြခဲ့သည့်အတိုင်း၊ ၎င်းသည် မန်နီးဖက်စ်ရှိ တောင်းဆိုချက်/ကန့်သတ်မှုအချိုးအပေါ်အခြေခံ၍ အချိုးကျစကေးချဲ့ခြင်းဖြစ်သည်-

• CPU: 200m → 300m: အချိုး 1:1.75;

• မန်မိုရီ- 250Mi → 500Mi: အချိုး 1:2။

နှငျ့ ပတျသကျ. HPAဒါဆို လည်ပတ်မှု ယန္တရားက ပိုပွင့်လင်းတယ်။ CPU နှင့် Memory ကဲ့သို့သော မက်ထရစ်များကို ကန့်သတ်ထားပြီး၊ ပုံတူအားလုံး၏ ပျမ်းမျှပမာဏသည် သတ်မှတ်ချက်ထက်ကျော်လွန်ပါက၊ တန်ဖိုးသတ်မှတ်ချက်အောက်သို့ ကျဆင်းသွားသည်အထိ သို့မဟုတ် ပုံတူပွားမှု အများဆုံးအရေအတွက်သို့ မရောက်မချင်း အပလီကေးရှင်းကို +1 ခွဲဖြင့် ချိန်ညှိမည်ဖြစ်သည်။

ပုံအား https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231 မှ ရိုက်ယူထားသည်

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

6. Node Affinity နှင့် Pod Affinity အကြောင်း မမေ့ပါနှင့်

node များအားလုံးသည် တူညီသောဟာ့ဒ်ဝဲပေါ်တွင် အလုပ်လုပ်သည်မဟုတ်ပါ၊ ပေါ့ဒ်အားလုံးသည် တွက်ချက်မှုအထူးပြုသော အပလီကေးရှင်းများကို လုပ်ဆောင်ရန်မလိုအပ်ပါ။ Kubernetes ကို အသုံးပြု၍ node နှင့် pods များ၏ အထူးပြုမှုကို သတ်မှတ်ခွင့်ပြုသည်။ Node Affinity и Pod Affinity.

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

သင့်တွင် node နှစ်ခုရှိသည်- one with CPUType=HIGHFREQ နှင့် မြန်ဆန်သော cores အများအပြား၊ နောက်တစ်ခု MemoryType=HIGHMEMORY Memory ပိုမြန်ပြီး စွမ်းဆောင်ရည် ပိုမြန်ပါတယ်။ အလွယ်ဆုံးနည်းလမ်းမှာ node တစ်ခုသို့ deployment ကို သတ်မှတ်ရန်ဖြစ်သည်။ HIGHFREQအပိုင်းကို ပေါင်းထည့်ခြင်းဖြင့် spec ဤရွေးချယ်မှုစနစ်-

…
nodeSelector:
	CPUType: HIGHFREQ

ပိုမိုစျေးကြီးပြီး တိကျသောနည်းလမ်းကို အသုံးပြုရန်ဖြစ်သည်။ nodeAffinity လယ်၌ affinity аздела spec. ရွေးချယ်စရာနှစ်ခုရှိသည်။

• requiredDuringSchedulingIgnoredDuringExecution: hard setting (အချိန်ဇယားဆွဲသူသည် သီးခြား node များ (နှင့် အခြားမည်သည့်နေရာမှ) တွင်သာ pods များကို ဖြန့်ကျက်ပေးမည်);

• preferredDuringSchedulingIgnoredDuringExecution: ပျော့ပျောင်းသောဆက်တင် (အချိန်ဇယားဆွဲသူသည် သီးခြား node များသို့ ဖြန့်ကျက်ရန် ကြိုးစားမည်ဖြစ်ပြီး ၎င်းသည် ပျက်ကွက်ပါက၊ ၎င်းသည် နောက်ထပ်ရရှိနိုင်သည့် node သို့ ဖြန့်ကျက်ရန် ကြိုးစားလိမ့်မည်)။

ကဲ့သို့သော node အညွှန်းများကို စီမံခန့်ခွဲရန်အတွက် သီးခြား syntax ကို သင် သတ်မှတ်နိုင်သည်။ In, NotIn, Exists, DoesNotExist, Gt သို့မဟုတ် Lt. သို့သော်၊ ရှည်လျားသော အညွှန်းများစာရင်းတွင် ရှုပ်ထွေးသောနည်းလမ်းများသည် အရေးကြီးသောအခြေအနေများတွင် ဆုံးဖြတ်ချက်ချခြင်းကို နှေးကွေးစေကြောင်း သတိရပါ။ တစ်နည်းအားဖြင့် ရိုးရိုးရှင်းရှင်းထားပါ။

အထက်တွင်ဖော်ပြထားသည့်အတိုင်း Kubernetes သည် သင့်အား လက်ရှိ pods များ၏ ရင်းနှီးမှုကို သတ်မှတ်နိုင်စေပါသည်။ ဆိုလိုသည်မှာ၊ အချို့သော pods များသည် တူညီသောရရှိနိုင်မှုဇုန် (clouds အတွက်သက်ဆိုင်ရာ) သို့မဟုတ် node များတွင် အခြား pods များနှင့်အတူ အလုပ်လုပ်ကြောင်း သေချာစေနိုင်ပါသည်။

В podAffinity လယ်ကွင်း affinity аздела spec တူညီသောအကွက်များကို ကိစ္စရပ်တွင် ရရှိနိုင်သည်။ nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution и preferredDuringSchedulingIgnoredDuringExecution. တစ်ခုတည်းသော ခြားနားချက်က အဲဒါပါပဲ။ matchExpressions pods များကို ထိုတံဆိပ်ဖြင့် pod တစ်ခုကို လုပ်ဆောင်နေပြီးဖြစ်သော node တစ်ခုနှင့် ချိတ်ပါမည်။

Kubernetes သည်လည်း အကွက်တစ်ခုကို ပေးသည်။ podAntiAffinityဆန့်ကျင်ဘက်အနေနှင့်၊ pod ကို သီးခြား pods များပါသည့် node တစ်ခုနှင့် ချိတ်မထားပါ။

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

7. အာသဝေါတရားနှင့် သည်းခံခြင်းတရား

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

အာသဝေါတရားတို့၏ ယန္တရား—သိက္ခာပုဒ်ကို တားမြစ်ခြင်း—ဤသို့ ကူညီပေး၏။ ဥပမာအားဖြင့်၊ အချို့သောအခြေအနေများတွင် သင်သည် pods များလည်ပတ်ခြင်းမှ အချို့သော node များကို တားမြစ်နိုင်သည်။ သီးခြား node တစ်ခုတွင် ညစ်ညမ်းမှုကို အသုံးချရန် ရွေးချယ်ခွင့်ကို သင်အသုံးပြုရန် လိုအပ်သည်။ taint kubectl တွင် သော့နဲ့တန်ဖိုးကို သတ်မှတ်ပြီးတော့ ညစ်ညမ်းတာမျိုး NoSchedule သို့မဟုတ် NoExecute:

$ kubectl taint nodes node10 node-role.kubernetes.io/ingress=true:NoSchedule

ညစ်ညမ်းမှုယန္တရားသည် အဓိကအကျိုးသက်ရောက်မှုသုံးခုကို ပံ့ပိုးပေးကြောင်းကိုလည်း သတိပြုသင့်ပါသည်။ NoSchedule, NoExecute и PreferNoSchedule.

• NoSchedule ဆိုလိုတာက အခုအချိန်မှာ pod specification မှာ သက်ဆိုင်တဲ့ entry တွေ ရှိတော့မှာ မဟုတ်ပါဘူး။ tolerations၊ ၎င်းသည် node ပေါ်တွင် deploy လုပ်လိမ့်မည်မဟုတ်ပါ (ဤဥပမာတွင် node10).

• PreferNoSchedule - ရိုးရှင်းသောဗားရှင်း NoSchedule. ဤကိစ္စတွင်၊ အချိန်ဇယားဆွဲသူသည် ကိုက်ညီသော entry မပါသော pods များကို ခွဲဝေမပေးရန် ကြိုးစားပါမည်။ tolerations node တစ်ခုစီ၊ ဒါပေမယ့် ဒါက ခက်ခဲတဲ့ ကန့်သတ်ချက် မဟုတ်ပါဘူး။ အစုအဝေးတွင် ရင်းမြစ်များမရှိပါက၊ pods များသည် ဤ node ပေါ်တွင် စတင်အသုံးပြုနိုင်မည်ဖြစ်သည်။

• NoExecute - ဤအကျိုးသက်ရောက်မှုသည် သက်ဆိုင်ရာ entry များမရှိသော pods များကို ချက်ခြင်းရွှေ့ပြောင်းရန် အစပျိုးပေးပါသည်။ tolerations.

စိတ်ဝင်စားစရာကောင်းသည်မှာ၊ ဤအပြုအမူကိုသည်းခံခြင်းယန္တရားသုံးပြီးပယ်ဖျက်နိုင်သည်။ "တားမြစ်ထားသော" node တစ်ခုရှိသောအခါတွင်၎င်းသည်အဆင်ပြေပြီး၎င်းပေါ်တွင်အခြေခံအဆောက်အအုံဝန်ဆောင်မှုများကိုသာသင်ထားရန်လိုအပ်သည်။ ဘယ်လို လုပ်ရမလဲ? သင့်လျော်သော ခံနိုင်ရည်ရှိသော အဆိုပါ pods များကိုသာ ခွင့်ပြုပါ။

ဤတွင် pod specification သည်မည်ကဲ့သို့ဖြစ်မည်နည်း။

spec:
   tolerations:
     - key: "node-role.kubernetes.io/ingress"
        operator: "Equal"
        value: "true"
        effect: "NoSchedule"

၎င်းသည် နောက်တစ်ကြိမ် ပြန်လည်အသုံးချခြင်းသည် ဤအထူး Node ပေါ်တွင် ကျရောက်မည်ဟု မဆိုလိုပါ၊ ၎င်းသည် Node Affinity ယန္တရားမဟုတ်ပါ၊ nodeSelector. သို့သော် အင်္ဂါရပ်များစွာကို ပေါင်းစပ်ခြင်းဖြင့် သင်သည် အလွန်ပြောင်းလွယ်ပြင်လွယ် အချိန်ဇယားဆွဲခြင်း ဆက်တင်များကို သင်ရရှိနိုင်ပါသည်။

8. Pod Deployment ကို ဦးစားပေး သတ်မှတ်ပါ။

သင့်တွင် node များအတွက် သတ်မှတ်ပေးထားသော pods များရှိနေ၍ pods အားလုံးကို တူညီသောဦးစားပေးဖြင့် ဆက်ဆံရမည်ဟု မဆိုလိုပါ။ ဥပမာအားဖြင့်၊ သင်သည် အချို့သော pods များကို အခြားသူများရှေ့တွင် အသုံးချလိုပေမည်။

Kubernetes သည် Pod Priority နှင့် Preemption ကို စီစဉ်သတ်မှတ်ရန် မတူညီသောနည်းလမ်းများကို ပေးဆောင်သည်။ ဆက်တင်တွင် အစိတ်အပိုင်းများစွာ ပါဝင်သည်- အရာဝတ္ထု PriorityClass နှင့် အကွက်ဖော်ပြချက်များ priorityClassName pod specification ထဲမှာ။ ဥပမာတစ်ခုကိုကြည့်ရအောင်။

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 99999
globalDefault: false
description: "This priority class should be used for very important pods only"

ငါတို့ဖန်တီးတယ်။ PriorityClassအမည်၊ ဖော်ပြချက်နှင့် တန်ဖိုးတစ်ခုပေးပါ။ ပိုမြင့်သည် valueဦးစားပေးလေ၊ တန်ဖိုးသည် 32-bit ကိန်းပြည့် 1 ထက်နည်းသည့် သို့မဟုတ် ညီမျှနိုင်သည်။ ယေဘုယျအားဖြင့် ကြိုတင်မကြိုတင်မရနိုင်သော mission-critical system pods များအတွက် သီးသန့်တန်ဖိုးများ။ ဦးစားပေးအဆင့်မြင့် pod သည် လှည့်ရန်နေရာမရှိမှသာ နေရာရွှေ့ပြောင်းမှုဖြစ်ပေါ်မည်ဖြစ်ပြီး၊ အချို့သော node တစ်ခုမှ pods များကို ဖယ်ထုတ်မည်ဖြစ်သည်။ ဤယန္တရားသည် သင့်အတွက် တင်းကျပ်လွန်းပါက၊ သင်သည် ရွေးချယ်မှုကို ထည့်နိုင်သည်။ preemptionPolicy: Never၊ ထို့နောက် ကြိုတင်မှာယူခြင်း မရှိတော့ပါ၊ pod သည် တန်းစီခြင်းတွင် ဦးစွာရပ်မည်ဖြစ်ပြီး ၎င်းအတွက် အခမဲ့အရင်းအမြစ်များကို ရှာဖွေရန် စီစဉ်သူအား စောင့်ဆိုင်းမည်ဖြစ်သည်။

ထို့နောက် ကျွန်ုပ်တို့သည် အမည်ကိုညွှန်ပြသည့် pod တစ်ခုကို ဖန်တီးသည်။ priorityClassName:

apiVersion: v1
kind: Pod
metadata:
  name: static-web
  labels:
    role: myrole
 spec:
  containers:
    - name: web
      image: nginx
      ports:
        - name: web
          containerPort: 80
          protocol: TCP
  priorityClassName: high-priority
          

ဦးစားပေးအတန်းများကို သင်နှစ်သက်သလောက် ဖန်တီးနိုင်သော်လည်း ၎င်းကို မဖယ်ထုတ်ရန် အကြံပြုထားသော်လည်း (ပြောပါ၊ သင့်ကိုယ်သင် အနိမ့်၊ အလယ်အလတ်နှင့် မြင့်မားသောဦးစားပေးအဖြစ် ကန့်သတ်ထားပါ)။

ထို့ကြောင့် လိုအပ်ပါက၊ သင်သည် nginx-ingress-controller၊ coredns စသည်တို့ကဲ့သို့ အရေးကြီးသော ဝန်ဆောင်မှုများကို ဖြန့်ကျက်ခြင်း၏ ထိရောက်မှုကို တိုးမြှင့်နိုင်သည်။

9. ETCD အစုအဝေးကို အကောင်းဆုံးဖြစ်အောင်လုပ်ပါ။

ETCD ကို အစုအဖွဲ့တစ်ခုလုံး၏ ဦးနှောက်ဟု ခေါ်နိုင်သည်။ Cube ၏ လည်ပတ်မှုအမြန်နှုန်းသည် ၎င်းပေါ်တွင်မူတည်သောကြောင့် ဤဒေတာဘေ့စ်၏ လုပ်ဆောင်ချက်ကို မြင့်မားသောအဆင့်တွင် ထိန်းသိမ်းထားရန် အလွန်အရေးကြီးပါသည်။ မျှတသောစံနှုန်းတစ်ခုဖြစ်ပြီး တစ်ချိန်တည်းတွင်၊ ကောင်းသောဖြေရှင်းချက်မှာ kube-apiserver သို့ အနည်းဆုံးနှောင့်နှေးစေရန်အတွက် ETCD cluster ကို master node များပေါ်တွင်ထားရန်ဖြစ်သည်။ သင်ဤသို့မလုပ်နိုင်ပါက ပါဝင်သူများကြားတွင် bandwidth ကောင်းကောင်းဖြင့် ETCD ကို တတ်နိုင်သမျှ နီးစပ်အောင်ထားပါ။ ETCD မှ node မည်မျှ အစုအဝေးမှ ထိခိုက်မှုမရှိဘဲ ထွက်သွားနိုင်ကြောင်းကိုလည်း အာရုံစိုက်ပါ။

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

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

1. အစုအဝေး၏အရွယ်အစားပေါ်မူတည်၍ ကောင်းမွန်သော ဟာ့ဒ်ဝဲရှိပါ (သင်ဖတ်ရှုနိုင်ပါသည်။ ဒီမှာ).

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

ကောက်ချက်

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

source: www.habr.com