🥇 Kubernetes Pod ရင်းမြစ်များကို ဘယ်လိုရယူရမလဲ

Tohad ၏ဆုလာဘ်

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

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

အဖွဲ့ Mail.ru မှ Kubernetes aaS ကွန်တိန်နာအရင်းအမြစ်များ (CPU နှင့် MEM)၊ တောင်းဆိုမှုများနှင့် အရင်းအမြစ်ကန့်သတ်ချက်များအကြောင်း ဆောင်းပါးကို ဘာသာပြန်ဆိုထားသည်။ ဤဆက်တင်များ၏ အကျိုးကျေးဇူးများနှင့် ၎င်းတို့ကို သင်မသတ်မှတ်ပါက မည်သို့ဖြစ်မည်ကို လေ့လာနိုင်မည်ဖြစ်သည်။

ကွန်ပျူတာအရင်းအမြစ်များ

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

ဗဟိုလုပ်ဆောင်မှုယူနစ် (CPU) - cores;
မန်မိုရီ (MEM) - ဘိုက်။

ကွန်တိန်နာတစ်ခုစီအတွက် အရင်းအမြစ်များကို သတ်မှတ်ထားသည်။ အောက်ပါ Pod YAML ဖိုင်တွင်၊ တောင်းဆိုထားသော အရင်းအမြစ်များနှင့် ကန့်သတ်ထားသော အရင်းအမြစ်များပါရှိသော အရင်းအမြစ်ကဏ္ဍကို သင်တွေ့မြင်ရလိမ့်မည်-

တောင်းဆိုထားသော Pod အရင်းအမြစ်များ = ကွန်တိန်နာအားလုံး၏ တောင်းဆိုထားသော အရင်းအမြစ်များ ပေါင်းစု;
Pod အရင်းအမြစ်ကန့်သတ်ချက် = Pod အရင်းအမြစ်ကန့်သတ်ချက်အားလုံး၏ ပေါင်းစု။

apiVersion: v1
kind: Pod
metadata:
  name: backend-pod-name
  labels:
    application: backend
spec:
  containers:
    — name: main-container
      image: my-backend
      tag: v1
      ports:
      — containerPort: 8080
      resources:
        requests:
          cpu: 0.2 # REQUESTED CPU: 200m cores
          memory: "1Gi" # REQUESTED MEM: 1Gi
        limits:
          cpu: 1 # MAX CPU USAGE: 1 core
          memory: "1Gi" # MAX MEM USAGE:  1Gi
    — name: other-container
      image: other-app
      tag: v1
      ports:
      — containerPort: 8000
      resources:
        requests:
          cpu: "200m" # REQUESTED CPU: 200m cores
          memory: "0.5Gi" # REQUESTED MEM: 0.5Gi
        limits:
          cpu: 1 # MAX CPU USAGE: 1 core
          memory: "1Gi" # MAX MEM USAGE:  1Gi

တောင်းဆိုထားသော နှင့် အကန့်အသတ်ရှိသော အရင်းအမြစ်များ ဥပမာ

လယ်ယာ resources.requested specification Pod သည် လိုချင်သော node ကိုရှာဖွေရန်အသုံးပြုသော element တစ်ခုဖြစ်သည်။ ၎င်းအတွက် Pod ဖြန့်ကျက်ခြင်းကို သင်စီစဉ်ပြီးဖြစ်သည်။ သင့်လျော်သော node ကိုသင်မည်သို့ရှာဖွေသနည်း။

Kubernetes တွင် master node သို့မဟုတ် master node (Kubernetes Control Plane) အပါအဝင် အစိတ်အပိုင်းများစွာ ပါဝင်သည်။ master node တွင် လုပ်ငန်းစဉ်များစွာ ရှိသည်- kube-apiserver၊ kube-controller-manager နှင့် kube-scheduler။

kube-scheduler လုပ်ငန်းစဉ်သည် အသစ်ဖန်တီးထားသော pods များကို ပြန်လည်သုံးသပ်ရန်နှင့် တောင်းဆိုထားသည့် အရင်းအမြစ်အရေအတွက်အပါအဝင် pod တောင်းဆိုမှုအားလုံးနှင့် ကိုက်ညီသော ဖြစ်နိုင်သည့် worker node များကို ရှာဖွေရန် တာဝန်ရှိပါသည်။ kube-scheduler မှတွေ့ရှိသော node များစာရင်းကို အဆင့်သတ်မှတ်ထားသည်။ pod ကို အမြင့်ဆုံးရမှတ်များနှင့်အတူ node တွင်စီစဉ်ထားသည်။

ခရမ်းရောင် Pod ကို ဘယ်မှာထားမလဲ။

ပုံတွင် kube-scheduler သည် ခရမ်းရောင် Pod အသစ်ကို အချိန်ဇယားဆွဲသင့်သည်ကို သင်တွေ့နိုင်သည်။ Kubernetes အစုအဝေးတွင် A နှင့် B တွင် node နှစ်ခုပါရှိသည်။ သင်တွေ့မြင်ရသည့်အတိုင်း၊ kube-scheduler သည် node A ရှိ Pod တစ်ခုအား အချိန်ဇယားဆွဲ၍မရပါ - ရရှိနိုင်သော (မတောင်းဆိုထားသော) ရင်းမြစ်များသည် ခရမ်းရောင် Pod ၏တောင်းဆိုမှုများနှင့် မကိုက်ညီပါ။ ထို့ကြောင့် ခရမ်းရောင် Pod မှတောင်းဆိုထားသော 1 GB မမ်မိုရီသည် node A တွင် အံမဝင်ပါ၊ ရရှိနိုင်သောမမ်မိုရီမှာ 0,5 GB ဖြစ်သည်။ ဒါပေမယ့် node B မှာ လုံလောက်တဲ့အရင်းအမြစ်တွေရှိပါတယ်။ ရလဒ်အနေဖြင့် kube-scheduler သည် ခရမ်းရောင် Pod ၏ ဦးတည်ရာသည် node B ဖြစ်သည်ဟု ဆုံးဖြတ်သည်။

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

အရင်းအမြစ်ကန့်သတ်ချက်သည် CPU/MEM ဖြတ်ကျော်၍မရသော နယ်နိမိတ်တစ်ခုဖြစ်သည်။ သို့သော်၊ CPU အရင်းအမြစ်သည် ပြောင်းလွယ်ပြင်လွယ်ဖြစ်သောကြောင့် ၎င်းတို့၏ CPU ကန့်သတ်ချက်သို့ရောက်ရှိသော ကွန်တိန်နာများသည် Pod ကို ထွက်ပေါက်ဖြစ်စေမည်မဟုတ်ပါ။ ယင်းအစား၊ CPU ပိတ်ဆို့ခြင်း စတင်ပါမည်။ MEM အသုံးပြုမှု ကန့်သတ်ချက် ပြည့်သွားပါက၊ OOM-Killer ကြောင့် ကွန်တိန်နာကို ရပ်တန့်ပြီး RestartPolicy ဆက်တင်မှ ခွင့်ပြုပါက ပြန်လည်စတင်မည်ဖြစ်သည်။

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

Docker နှင့် Kubernetes အကြား အရင်းအမြစ်ဆက်သွယ်ရေး

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

မှတ်ဉာဏ်- တောင်းဆိုမှုနှင့် ကန့်သတ်ချက်

containers:
...
 resources:
   requests:
     memory: "0.5Gi"
   limits:
     memory: "1Gi"

အထက်တွင်ဖော်ပြခဲ့သည့်အတိုင်း memory ကို bytes ဖြင့်တိုင်းတာသည်။ ပေါ်အခြေခံကာ Kubernetes စာရွက်စာတမ်းMemory ကို နံပါတ်တစ်ခုအနေနဲ့ သတ်မှတ်နိုင်ပါတယ်။ အများအားဖြင့် ၎င်းသည် ကိန်းပြည့်၊ ဥပမာ 2678 - ဆိုလိုသည်မှာ 2678 bytes ဖြစ်သည်။ နောက်ဆက်တွဲများကိုလည်း သုံးနိုင်သည်။ G и Giအဓိကကတော့ သူတို့ဟာ မညီမျှဘူးဆိုတာ သတိရဖို့ပါပဲ။ ပထမသည် ဒဿမဖြစ်ပြီး ဒုတိယမှာ ဒွိကိန်းဖြစ်သည်။ k8s documentation တွင်ဖော်ပြထားသော ဥပမာကဲ့သို့ပင်။ 128974848, 129e6, 129M, 123Mi - ၎င်းတို့သည် လက်တွေ့တွင် တူညီသည်။

Kubernetes ရွေးချယ်မှု limits.memory အလံနှင့်ကိုက်ညီသည်။ --memory Docker မှ အမှုကိစ္စ request.memory Docker သည် ဤအကွက်ကို အသုံးမပြုသောကြောင့် Docker အတွက် မျှားမရှိပါ။ ဒါတောင် လိုအပ်လို့လားလို့ မေးနိုင်ပါတယ်။ ဟုတ်တယ် လိုအပ်တယ်။ အရင်ကပြောခဲ့သလိုပဲ၊ နယ်ပယ်က Kubernetes အတွက် အရေးကြီးတယ်။ ၎င်းမှအချက်အလက်များအပေါ်အခြေခံ၍ kube-scheduler သည် Pod ကိုအချိန်ဇယားဆွဲရန် မည်သည့် node ကိုဆုံးဖြတ်သည်။

တောင်းဆိုချက်တစ်ခုအတွက် မှတ်ဉာဏ်မလုံလောက်ပါက မည်သို့ဖြစ်မည်နည်း။

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

မမ်မိုရီကန့်သတ်ချက် အလွန်နည်းပါက မည်သို့ဖြစ်မည်နည်း။

ကွန်တိန်နာသည် မမ်မိုရီကန့်သတ်ချက်ထက်ကျော်လွန်ပါက OOM-Killed ကြောင့် ၎င်းကို ရပ်စဲသွားမည်ဖြစ်သည်။ မူလတန်ဖိုးရှိသည့် RestartPolicy ကိုအခြေခံ၍ ဖြစ်နိုင်ပါက ပြန်လည်စတင်ပါမည်။ Always.

တောင်းဆိုထားတဲ့ memory ကို မသတ်မှတ်ရင် ဘာဖြစ်မလဲ။

Kubernetes သည် ကန့်သတ်တန်ဖိုးကို ယူကာ မူရင်းတန်ဖိုးအဖြစ် သတ်မှတ်မည်ဖြစ်သည်။

မမ်မိုရီကန့်သတ်ချက်ကို မသတ်မှတ်ပါက ဘာဖြစ်နိုင်မလဲ။

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

မမ်မိုရီကန့်သတ်ချက် မသတ်မှတ်ရင် ဘာဖြစ်မလဲ။

ဤသည်မှာ အဆိုးဆုံးအခြေအနေဖြစ်သည်- အချိန်ဇယားဆွဲသူသည် ကွန်တိန်နာတွင် အရင်းအမြစ်မည်မျှလိုအပ်သည်ကို မသိဘဲ၊ ၎င်းသည် node တွင် ဆိုးရွားသောပြဿနာများကို ဖြစ်စေနိုင်သည်။ ဤကိစ္စတွင်၊ namespace (LimitRange အားဖြင့်သတ်မှတ်သည်) တွင်မူလကန့်သတ်ချက်များရှိရန်ကောင်းလိမ့်မည်။ ပုံသေကန့်သတ်ချက်များမရှိပါ - Pod သည် အကန့်အသတ်မရှိ၊ ၎င်းသည် လိုချင်သလောက် memory ကိုအသုံးပြုနိုင်သည်။

တောင်းဆိုထားသောမှတ်ဉာဏ်သည် node မှပေးဆောင်နိုင်သောပမာဏထက်ပိုပါက Pod ကိုစီစဉ်မည်မဟုတ်ပါ။ အဲဒါကို မှတ်ထားဖို့ အရေးကြီးတယ်။ Requests.memory - အနိမ့်ဆုံးတန်ဖိုးမဟုတ်ပါ။ ဤအရာသည် ကွန်တိန်နာကို စဉ်ဆက်မပြတ်လည်ပတ်နေစေရန် လုံလောက်သော memory ပမာဏ၏ ဖော်ပြချက်ဖြစ်သည်။

၎င်းသည် အများအားဖြင့် တူညီသောတန်ဖိုးကို သတ်မှတ်ရန် အကြံပြုထားသည်။ request.memory и limit.memory. ၎င်းသည် Kubernetes သည် Pod ကိုလည်ပတ်ရန် လုံလောက်သော memory ပါသည့် node တစ်ခုပေါ်တွင် Pod တစ်ခုကို အချိန်ဇယားဆွဲမည်မဟုတ်သော်လည်း ၎င်းကိုလည်ပတ်ရန်မလုံလောက်ကြောင်းသေချာစေသည်။ မှတ်သားထားပါ- Kubernetes Pod အစီအစဉ်ရေးဆွဲခြင်းသည်သာ ထည့်သွင်းစဉ်းစားပါသည်။ requests.memoryနှင့် limits.memory အကောင့်ထဲသို့ထည့်မထားဘူး။

CPU- တောင်းဆိုချက်နှင့် ကန့်သတ်ချက်

containers:
...
 resources:
   requests:
     cpu: 1
   limits:
     cpu: "1200m"

CPU နဲ့ဆို အရာအားလုံးက နည်းနည်းပိုရှုပ်ထွေးပါတယ်။ Kubernetes နှင့် Docker အကြား ဆက်ဆံရေးပုံသို့ ပြန်သွားသောအခါ ၎င်းကို သင်တွေ့မြင်နိုင်သည်။ request.cpu ကိုက်ညီ --cpu-sharesသော်လည်း limit.cpu အလံနှင့်ကိုက်ညီသည်။ cpus Docker တွင်။

Kubernetes တောင်းဆိုသော CPU ကို CPU လည်ပတ်မှုအချိုးအစား 1024 ဖြင့် မြှောက်ထားသည်။ core အပြည့် 1 ကို တောင်းဆိုလိုပါက ထည့်ရပါမည်။ cpu: 1အထက်တွင်ပြထားသည့်အတိုင်း။

kernel အပြည့်အစုံ (အချိုး = 1024) တောင်းဆိုခြင်းသည် သင့်ကွန်တိန်နာကို လက်ခံရရှိမည်ဟု မဆိုလိုပါ။ အကယ်၍ သင့်အိမ်ရှင်စက်တွင် core တစ်ခုသာရှိပြီး သင်သည် ကွန်တိန်နာတစ်ခုထက်ပို၍ လုပ်ဆောင်နေပါက၊ ကွန်တိန်နာများအားလုံးသည် ၎င်းတို့ကြားတွင် ရရှိနိုင်သော CPU ကို မျှဝေရမည်ဖြစ်သည်။ ဒါက ဘယ်လိုဖြစ်တာလဲ။ ပုံကိုကြည့်လိုက်ရအောင်။

CPU တောင်းဆိုမှု - Single Core စနစ်

သင့်တွင် single-core host စနစ်ဖြင့် ကွန်တိန်နာများ လည်ပတ်နေပုံကို စိတ်ကူးကြည့်ကြပါစို့။ အမေ (Kubernetes) သည် ပီပီ (CPU) ကို ဖုတ်ပြီး ကလေးများ (ကွန်တိန်နာများ) အကြား ခွဲပေးလိုသည်။ ကလေးသုံးယောက်က မုန့်လုံးတစ်လုံးလိုချင်တယ် (အချိုး = 1024)၊ နောက်ကလေးက ပီနံတစ်ဝက် (512) လိုချင်တယ်။ အမေက တရားမျှတပြီး ရိုးရှင်းတဲ့ တွက်ချက်မှုကို လိုချင်တယ်။

# Сколько пирогов хотят дети?
# 3 ребенка хотят по целому пирогу и еще один хочет половину пирога
cakesNumberKidsWant = (3 * 1) + (1 * 0.5) = 3.5
# Выражение получается так:
3 (ребенка/контейнера) * 1 (целый пирог/полное ядро) + 1 (ребенок/контейнер) * 0.5 (половина пирога/половина ядра)
# Сколько пирогов испечено?
availableCakesNumber = 1
# Сколько пирога (максимально) дети реально могут получить?
newMaxRequest = 1 / 3.5 =~ 28%

တွက်ချက်မှုအပေါ် အခြေခံ၍ ကလေးသုံးဦးသည် အူတိုင်၏ 28% ရရှိမည်ဖြစ်ပြီး အူတိုင်တစ်ခုလုံးမဟုတ်ပေ။ စတုတ္ထကလေးသည် ထက်ဝက်မဟုတ်ဘဲ ကာနယ်အပြည့်၏ 14% ရရှိမည်ဖြစ်သည်။ ဒါပေမယ့် Multi-Core စနစ်တစ်ခုရှိရင်တော့ ကွဲပြားသွားမှာပါ။

CPU Request - Multi-Core (4) စနစ်

အပေါ်ကပုံမှာ ကလေးသုံးယောက်က မုန့်လုံးလိုချင်ပြီး တစ်ယောက်က တစ်ဝက်လိုချင်တာကို တွေ့နိုင်ပါတယ်။ မေမေက ပီယာလေးလုံး ဖုတ်တဲ့အတွက် သားသမီးတိုင်း လိုချင်သလောက် များများရလိမ့်မယ်။ Multi-core စနစ်တွင် ပရိုဆက်ဆာအရင်းအမြစ်များကို ရရှိနိုင်သော ပရိုဆက်ဆာ cores အားလုံးကို ဖြန့်ဝေပါသည်။ ကွန်တိန်နာတစ်ခုသည် CPU core တစ်ခုထက်နည်းသော ကန့်သတ်ထားပါက ၎င်းကို 100% တွင် ဆက်လက်အသုံးပြုနိုင်ပါသည်။

အထက်ဖော်ပြပါ တွက်ချက်မှုများသည် CPU ကို ကွန်တိန်နာများကြားတွင် မည်သို့ဖြန့်ဝေသည်ကို နားလည်ရန် ရိုးရှင်းပါသည်။ ဟုတ်ပါတယ်၊ ကွန်တိန်နာများကိုယ်တိုင်အပြင်၊ CPU အရင်းအမြစ်များကိုလည်း အသုံးပြုသည့် အခြားသော လုပ်ငန်းစဉ်များလည်း ရှိသေးသည်။ ကွန်တိန်နာတစ်ခုရှိ လုပ်ငန်းစဉ်များသည် အလုပ်မလုပ်သောအခါ၊ အခြားသူများက ၎င်း၏အရင်းအမြစ်ကို အသုံးပြုနိုင်သည်။ CPU: "200m" ကိုက်ညီ CPU: 0,2ဆိုလိုသည်မှာ core တစ်ခု၏ 20% ခန့်ကို ဆိုလိုသည်။

ကဲ အကြောင်းပြောကြရအောင် limit.cpu. Kubernetes ကန့်သတ်ထားသော CPU ကို 100 ဖြင့် မြှောက်ထားသည်။ ရလဒ်မှာ ကွန်တိန်နာသည် 100 µs တိုင်း အသုံးပြုနိုင်သည့် အချိန်ပမာဏ (cpu-period).

limit.cpu Docker အလံနှင့် ကိုက်ညီသည်။ --cpus. ဒါက အဟောင်း ပေါင်းစပ်မှု အသစ်ပါ။ --cpu-period и --cpu-quota. ၎င်းကို သတ်မှတ်ခြင်းဖြင့်၊ ပိတ်ဆို့ခြင်းမစတင်မီ ကွန်တိန်နာတွင် ကွန်တိန်နာတွင် အများဆုံးအသုံးပြုနိုင်သည့် ရရှိနိုင်သော CPU အရင်းအမြစ် မည်မျှရှိသည်ကို ကျွန်ုပ်တို့ညွှန်ပြသည်-

cpus - ပေါင်းစပ် cpu-period и cpu-quota. cpus = 1.5 setting နှင့်ညီမျှသည်။ cpu-period = 100000 и cpu-quota = 150000;
CPU-ခေတ် - ကာလ CPU CFS အချိန်ဇယားပုံသေ 100 မိုက်ခရိုစက္ကန့်၊
cpu-ခွဲတမ်း - အတွင်းမှ မိုက်ခရိုစက္ကန့် အရေအတွက် cpu-periodကွန်တိန်နာဖြင့် ကန့်သတ်ထားသည်။

တောင်းဆိုထားသော CPU မလုံလောက်ပါက မည်သို့ဖြစ်မည်နည်း။

ကွန်တိန်နာသည် ၎င်းတွင်ထည့်သွင်းထားသည်ထက် ပိုမိုလိုအပ်ပါက၊ ၎င်းသည် CPU ကို အခြားလုပ်ငန်းစဉ်များမှ ခိုးယူမည်ဖြစ်သည်။

CPU ကန့်သတ်ချက် အလွန်နည်းရင် ဘာဖြစ်မလဲ။

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

CPU တောင်းဆိုချက်ကို မသတ်မှတ်ပါက ဘာဖြစ်မလဲ။

မန်မိုရီကဲ့သို့ပင်၊ တောင်းဆိုချက်တန်ဖိုးသည် ကန့်သတ်ချက်နှင့် ညီသည်။

CPU ကန့်သတ်ချက်ကို မသတ်မှတ်ပါက ဘာဖြစ်မလဲ။

ကွန်တိန်နာသည် လိုအပ်သလောက် CPU ကို အသုံးပြုမည်ဖြစ်သည်။ မူရင်း CPU ပေါ်လစီ (LimitRange) ကို namespace တွင် သတ်မှတ်ပါက၊ ဤကန့်သတ်ချက်ကို ကွန်တိန်နာအတွက်လည်း အသုံးပြုပါသည်။

တောင်းဆိုချက်တစ်ခု သို့မဟုတ် CPU ကန့်သတ်ချက်ကို သင်မသတ်မှတ်ပါက မည်သို့ဖြစ်မည်နည်း။

မှတ်ဉာဏ်ကဲ့သို့ပင်၊ ဤသည်မှာ အဆိုးဆုံးအခြေအနေဖြစ်သည်။ အချိန်ဇယားဆွဲသူသည် သင့်ကွန်တိန်နာအတွက် ရင်းမြစ်မည်မျှလိုအပ်သည်ကို မသိပါ၊ ၎င်းသည် node တွင် ဆိုးရွားသောပြဿနာများကို ဖြစ်စေနိုင်သည်။ ၎င်းကိုရှောင်ရှားရန်၊ namespaces (LimitRange) အတွက် ပုံသေကန့်သတ်ချက်များကို သင်သတ်မှတ်ရန်လိုအပ်သည်။

သတိရပါ- သင်သည် node များပေးစွမ်းနိုင်သော CPU ထက်ပိုမိုတောင်းဆိုပါက Pod ကိုစီစဉ်မည်မဟုတ်ပါ။ Requests.cpu - အနိမ့်ဆုံးတန်ဖိုးမဟုတ်သော်လည်း Pod ကိုစတင်၍ မအောင်မြင်ဘဲအလုပ်လုပ်ရန်လုံလောက်သောတန်ဖိုး။ အကယ်၍ အပလီကေးရှင်းသည် ရှုပ်ထွေးသောတွက်ချက်မှုများကို မလုပ်ဆောင်ပါက၊ အကောင်းဆုံးရွေးချယ်မှုမှာ ထည့်သွင်းရန်ဖြစ်သည်။ request.cpu <= 1 ပြီးလျှင် လိုအပ်သလို ပုံတူများစွာကို ဖွင့်ပါ။

တောင်းဆိုထားသော အရင်းအမြစ်များ သို့မဟုတ် အရင်းအမြစ်ကန့်သတ်ချက်၏ စံပြပမာဏ

ကွန်ပြူတာရင်းမြစ်များ၏ ကန့်သတ်ချက်များအကြောင်းကို ကျွန်ုပ်တို့ လေ့လာခဲ့သည်။ ယခုမေးခွန်းကိုဖြေရန်အချိန်ရောက်ပြီ- "ပြဿနာမရှိဘဲအပလီကေးရှင်းကိုဖွင့်ရန်ကျွန်ုပ်၏ Pod သည် အရင်းအမြစ်မည်မျှလိုအပ်သနည်း။ စံပြပမာဏက ဘယ်လောက်လဲ။

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

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

ဥပမာအနေနဲ့ ဒါကိုကြည့်ပါ။ Grafana ဒက်ရှ်ဘုတ်. ၎င်းသည် တောင်းဆိုထားသော အရင်းအမြစ်များ သို့မဟုတ် အရင်းအမြစ်ကန့်သတ်ချက်နှင့် လက်ရှိ အရင်းအမြစ်အသုံးပြုမှုတို့ကြား ခြားနားချက်ကို ပြသသည်။

ကောက်ချက်

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

အတိုချုပ်အားဖြင့်၊ မှတ်သားထားရမည့်အချက်အချို့ရှိပါသည်။

တောင်းဆိုထားသောရင်းမြစ်များသည် စတင်ချိန်၌ ထည့်သွင်းတွက်ချက်ထားသော ဖွဲ့စည်းမှုတစ်ခုဖြစ်သည် ( Kubernetes သည် အပလီကေးရှင်းကို လက်ခံကျင်းပရန် စီစဉ်သည့်အခါ)။ ဆန့်ကျင်ဘက်အားဖြင့်၊ အပလီကေးရှင်းသည် node ပေါ်တွင်လည်ပတ်နေသောအခါတွင် အရင်းအမြစ်များကို ကန့်သတ်ခြင်းသည် အရေးကြီးပါသည်။
မန်မိုရီနှင့် နှိုင်းယှဉ်ပါက CPU သည် ထိန်းချုပ်ထားသော အရင်းအမြစ်တစ်ခုဖြစ်သည်။ CPU အလုံအလောက်မရှိပါက၊ သင်၏ Pod သည် ပိတ်သွားမည်ဖြစ်ပြီး throttling ယန္တရားကို ဖွင့်ပါမည်။
တောင်းဆိုထားသော အရင်းအမြစ်များနှင့် အရင်းအမြစ်ကန့်သတ်ချက်သည် အနည်းဆုံးနှင့် အမြင့်ဆုံးတန်ဖိုးများ မဟုတ်ပါ။ တောင်းဆိုထားသော အရင်းအမြစ်များကို သတ်မှတ်ခြင်းဖြင့်၊ အပလီကေးရှင်းသည် ပြဿနာမရှိဘဲ လည်ပတ်နေမည်ကို သေချာပါသည်။
အလေ့အကျင့်ကောင်းတစ်ခုသည် memory တောင်းဆိုမှုကို memory limit နှင့်ညီအောင်သတ်မှတ်ရန်ဖြစ်သည်။
Ok install တောင်းဆိုထားသည်။ CPU <=1အပလီကေးရှင်းသည် ရှုပ်ထွေးသော တွက်ချက်မှုများကို မလုပ်ဆောင်ပါက၊
အကယ်၍ သင်သည် node တစ်ခုတွင်ရရှိနိုင်သည်ထက် အရင်းအမြစ်များကို ပိုမိုတောင်းဆိုပါက Pod ကို ထို node သို့ မည်သည့်အခါမှ စီစဉ်မည်မဟုတ်ပါ။
တောင်းဆိုထားသော အရင်းအမြစ်များ/အရင်းအမြစ်ကန့်သတ်ချက်များ၏ မှန်ကန်သောပမာဏကို ဆုံးဖြတ်ရန်၊ ဝန်စမ်းသပ်ခြင်းနှင့် စောင့်ကြည့်ခြင်းကို အသုံးပြုပါ။

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

ကံကောင်းပါစေ!

နောက်ထပ်ဖတ်စရာများ

source: www.habr.com