ProHoster > بلاګ > اداره > د کوبرنیټس پوډ سرچینو ته د لاسرسي څرنګوالی

د کوبرنیټس پوډ سرچینو ته د لاسرسي څرنګوالی

د کوبرنیټس پوډ سرچینو ته د لاسرسي څرنګوالید توحید لخوا انعام

کله چې د Kubernetes سره پیل کوئ، دا معمول دی چې د کانټینر سرچینو ترتیب کولو په اړه هیر کړئ. پدې مرحله کې ، دا د ډاډ ترلاسه کولو لپاره کافي دي چې د ډاکر عکس کار کوي او د کوبرنیټس کلسټر ته ځای په ځای کیدی شي.

مګر وروسته غوښتنلیک باید د نورو غوښتنلیکونو سره د تولید کلستر کې ځای په ځای شي. د دې کولو لپاره ، تاسو اړتیا لرئ د کانټینر لپاره سرچینې تخصیص کړئ او ډاډ ترلاسه کړئ چې د غوښتنلیک پورته کولو او چلولو لپاره کافي شتون لري ، او دا چې نور چلونکي غوښتنلیکونه به ستونزې تجربه نکړي.

ټیم Kubernetes aaS له Mail.ru څخه د کانټینر سرچینو (CPU او MEM) په اړه یوه مقاله ژباړل، غوښتنې او د سرچینو محدودیتونه. تاسو به د دې ترتیباتو ګټې زده کړئ او څه پیښیږي که تاسو یې تنظیم نه کړئ.

د کمپیوټري سرچینې

موږ د لاندې واحدونو سره دوه ډوله سرچینې لرو:

  • د مرکزي پروسس کولو واحد (CPU) - کورونه؛
  • حافظه (MEM) - بایټس.

سرچینې د هر کانټینر لپاره مشخص شوي. په لاندې Pod YAML فایل کې، تاسو به د سرچینې برخه وګورئ چې غوښتل شوي او محدود سرچینې لري:

  • غوښتل شوي پوډ سرچینې = د ټولو کانټینرونو غوښتنه شوې سرچینې؛
  • د پوډ سرچینې محدودیت = د پوډ سرچینو ټولو محدودیتونو مجموعه.

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 د مشخصاتو څخه پوډ یو له هغه عناصرو څخه دی چې د مطلوب نوډ موندلو لپاره کارول کیږي. تاسو کولی شئ دمخه د دې لپاره د پوډ ګمارنې پلان کړئ. تاسو څنګه یو مناسب نوډ ومومئ؟

Kubernetes د ډیری برخو څخه جوړ دی، په شمول د ماسټر نوډ یا ماسټر نوډ (Kubernetes Control Plane). ماسټر نوډ ډیری پروسې لري: کیوب اپیسرور، کیوب کنټرولر مدیر او کیوب شیډولر.

د کیوب - مهالویش پروسه د نوي رامینځته شوي پوډونو بیاکتنې او د احتمالي کارګر نوډونو موندلو مسؤلیت لري چې د پوډ ټولو غوښتنو سره سمون لري ، پشمول د غوښتل شوي سرچینو شمیر. د kube-scheduler لخوا موندل شوي نوډونو لیست درجه بندي شوی. پوډ د لوړې نمرو سره په نوډ کې ټاکل شوی.

د کوبرنیټس پوډ سرچینو ته د لاسرسي څرنګوالیارغواني پوډ به چیرته کیښودل شي؟

په عکس کې تاسو لیدلی شئ چې د کیوب شیډولر باید یو نوی ارغواني پوډ مهالویش کړي. د Kubernetes کلستر دوه نوډونه لري: A او B. لکه څنګه چې تاسو لیدلی شئ، کیوب-شیډولر نشي کولی په نوډ A کې پوډ مهالویش کړي - موجودې (ناغوښتل شوي) سرچینې د ارغواني پوډ غوښتنې سره سمون نه لري. نو، د ارغواني پوډ لخوا غوښتل شوي 1 GB حافظه به په نوډ A کې مناسب نه وي، ځکه چې موجود حافظه 0,5 GB ده. مګر نوډ B کافي سرچینې لري. د پایلې په توګه، د کیوب شیډولر پریکړه کوي چې د ارغواني پوډ منزل د نوډ B دی.

اوس موږ پوهیږو چې غوښتل شوي سرچینې څنګه د پوډ چلولو لپاره د نوډ انتخاب اغیزه کوي. مګر د محدودو سرچینو اغیزه څه ده؟

د سرچینې حد یو حد دی چې CPU/MEM نشي کولی تیر کړي. په هرصورت، د CPU سرچینه انعطاف وړ ده، نو هغه کانټینرونه چې د دوی د CPU حدونو ته رسیږي د پوډ د وتلو لامل نشي. پرځای یې، د CPU تروټلینګ به پیل شي. که چیرې د MEM کارونې حد ته ورسیږي، کانټینر به د OOM-Killer له امله ودریږي او بیا پیل شي که چیرې د RestartPolicy ترتیب لخوا اجازه ورکړل شي.

په تفصیل سره غوښتل شوي او اعظمي سرچینې

د کوبرنیټس پوډ سرچینو ته د لاسرسي څرنګوالید Docker او Kubernetes ترمنځ د سرچینې اړیکه

د دې تشریح کولو لپاره غوره لاره چې د سرچینو غوښتنې او د سرچینو محدودیتونه څنګه کار کوي د کوبرنیټس او ډاکر ترمینځ اړیکې معرفي کول دي. په پورته عکس کې تاسو لیدلی شئ چې د کوبرنیټس ساحې او د ډاکر پیل بیرغونه څنګه تړاو لري.

یادونه: غوښتنه او محدودیت

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

لکه څنګه چې پورته یادونه وشوه، حافظه په بایټ کې اندازه کیږي. پر بنسټ د Kubernetes اسناد، موږ کولی شو حافظه د شمیرې په توګه مشخص کړو. معمولا دا یو عدد دی، د بیلګې په توګه 2678 - دا دی، 2678 بایټ. تاسو کولی شئ ضمیمه هم وکاروئ G и Gi، اصلي شی دا دی چې په یاد ولرئ چې دوی مساوي ندي. لومړی یې ډیسیمال دی او دوهم یې بائنری دی. لکه د k8s اسنادو کې ذکر شوي مثال په څیر: 128974848, 129e6, 129M, 123Mi - دوی په عملي توګه مساوي دي.

د Kubernetes اختیار limits.memory بیرغ سره سمون خوري --memory د ډاکر څخه. په صورت کې request.memory د ډاکر لپاره هیڅ تیر شتون نلري ځکه چې ډاکر دا ساحه نه کاروي. تاسو شاید پوښتنه وکړئ، ایا دا حتی اړین دی؟ هو اړتیا لري. لکه څنګه چې ما مخکې وویل، ساحه د Kubernetes لپاره اهمیت لري. د دې څخه د معلوماتو پراساس ، کیوب شیډولر پریکړه کوي چې کوم نوډ د پوډ مهالویش وکړي.

څه پیښیږي که تاسو د غوښتنې لپاره کافي حافظه جوړه نه کړئ؟

که کانټینر د غوښتل شوي حافظې حد ته رسیدلی وي ، نو پوډ د پوډونو په یوه ګروپ کې ځای په ځای کیږي چې ودریږي کله چې په نوډ کې کافي حافظه شتون نلري.

څه پیښیږي که تاسو د حافظې حد ډیر ټیټ کړئ؟

که کانټینر د حافظې له حد څخه تیریږي، دا به د OOM-Killed له امله وتړل شي. او د امکان په صورت کې به د RestartPolicy پراساس بیا پیل شي چیرې چې ډیفالټ ارزښت وي Always.

څه پیښیږي که تاسو غوښتل شوې حافظه مشخص نه کړئ؟

Kubernetes به د حد ارزښت واخلي او د اصلي ارزښت په توګه به یې تنظیم کړي.

څه پیښ کیدی شي که تاسو د حافظې حد مشخص نه کړئ؟

کانټینر هیڅ محدودیت نلري؛ دا کولی شي څومره حافظه وکاروي څومره چې وغواړي. که هغه د نوډ ټولې موجودې حافظې کارول پیل کړي، نو OOM به هغه ووژني. بیا کانټینر به بیا پیل شي که امکان ولري د RestartPolicy پراساس.

څه پیښیږي که تاسو د حافظې محدودیتونه مشخص نه کړئ؟

دا ترټولو ناوړه قضیه ده: مهالویش کوونکی نه پوهیږي چې کانټینر څومره سرچینو ته اړتیا لري، او دا کولی شي په نوډ کې جدي ستونزې رامینځته کړي. په دې حالت کې، دا به ښه وي چې د نوم ځای کې ډیفالټ محدودیتونه ولرئ (د LimitRange لخوا ټاکل شوي). هیڅ ډیفالټ محدودیتونه شتون نلري - پوډ هیڅ محدودیت نلري ، دا کولی شي څومره حافظه وکاروي څومره چې وغواړي.

که غوښتنه شوې حافظه د نوډ وړاندیز کولو څخه ډیر وي ، پوډ به مهالویش نه وي. دا مهمه ده چې په یاد ولرئ Requests.memory - نه لږ تر لږه ارزښت. دا د کافي حافظې مقدار توضیح دی چې کانټینر په دوامداره توګه روان وساتي.

دا معمولا سپارښتنه کیږي چې ورته ارزښت ترتیب کړي request.memory и limit.memory. دا ډاډ ورکوي چې کوبرنیټس به په نوډ کې پوډ مهالویش ونه کړي چې د پوډ چلولو لپاره کافي حافظه ولري مګر د چلولو لپاره کافي ندي. په یاد ولرئ: د کوبرنیټس پوډ پلان جوړونه یوازې په پام کې نیسي requests.memoryاو limits.memory په پام کې نه نیسي.

CPU: غوښتنه او حد

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

د CPU سره هرڅه یو څه ډیر پیچلي دي. د کبرنیټس او ډاکر ترمینځ د اړیکو عکس ته راستنیدل ، تاسو کولی شئ دا وګورئ request.cpu د --cpu-shares، پداسې حال کې چې limit.cpu بیرغ سره سمون خوري cpus په ډاکر کې.

هغه CPU چې Kubernetes یې غوښتنه کوي د 1024 لخوا ضرب کیږي، د CPU دورې تناسب. که تاسو غواړئ د 1 بشپړ کور غوښتنه وکړئ، تاسو باید اضافه کړئ cpu: 1لکه څنګه چې پورته ښودل شوي.

د بشپړ کرنل غوښتنه کول (تناسب = 1024) پدې معنی ندي چې ستاسو کانټینر به یې ترلاسه کړي. که ستاسو کوربه ماشین یوازې یو کور ولري او تاسو له یو څخه ډیر کانټینر چلوئ ، نو ټول کانټینرونه باید د دوی ترمینځ موجود CPU شریک کړي. دا څنګه کیږي؟ راځئ چې انځور ته وګورو.

د کوبرنیټس پوډ سرچینو ته د لاسرسي څرنګوالی
د CPU غوښتنه - واحد کور سیسټم

راځئ چې تصور وکړو چې تاسو یو واحد کور کوربه سیسټم لرئ چې کانټینرونه چلوي. مور (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٪ ترلاسه کړي، نه نیمایي. مګر شیان به توپیر ولري که تاسو څو کور سیسټم ولرئ.

د کوبرنیټس پوډ سرچینو ته د لاسرسي څرنګوالی
د CPU غوښتنه - ملټي کور (4) سیسټم

په پورتني عکس کې تاسو لیدلی شئ چې درې ماشومان یو بشپړ پائی غواړي، او یو نیمایي غواړي. له هغه وخته چې مور څلور پائی پخوي، د هغې هر ماشوم به څومره چې دوی وغواړي ترلاسه کړي. په څو کور سیسټم کې، د پروسیسر سرچینې په ټولو موجود پروسیسر کورونو کې ویشل شوي. که چیرې یو کانټینر د یو بشپړ CPU کور څخه کم پورې محدود وي، دا لاهم کولی شي په 100٪ کې وکاروي.

پورتني حسابونه د دې لپاره ساده شوي چې پوه شي چې CPU څنګه د کانټینرونو ترمینځ ویشل کیږي. البته ، پخپله د کانټینرونو سربیره ، نورې پروسې هم شتون لري چې د CPU سرچینې هم کاروي. کله چې په یوه کانټینر کې پروسې بې کاره وي، نور کولی شي د هغې سرچینې وکاروي. CPU: "200m" د CPU: 0,2، دا پدې مانا ده چې د یوې کور شاوخوا 20٪.

اوس راځئ چې په اړه خبرې وکړو limit.cpu. CPU چې Kubernetes محدودوي د 100 لخوا ضرب کیږي. پایله د هغه وخت مقدار دی چې کانټینر کولی شي په هر 100 µs کې وکاروي (cpu-period).

limit.cpu د ډاکر بیرغ سره سمون لري --cpus. دا د زاړه ترکیب نوی دی --cpu-period и --cpu-quota. د دې په ترتیب کولو سره، موږ دا په ګوته کوو چې د CPU څومره سرچینې شتون لري چې کانټینر کولی شي په اعظمي توګه د تروټلینګ پیل کولو دمخه وکاروي:

  • cpus - ترکیب cpu-period и cpu-quota. cpus = 1.5 د ترتیب سره برابر cpu-period = 100000 и cpu-quota = 150000;
  • CPU- دوره - دوره د CPU CFS مهالویش کونکی, ډیفالټ 100 مایکرو ثانیه؛
  • cpu- کوټه - دننه د مایکرو ثانیو شمیر cpu-period، کوم چې د کانټینر لخوا تړل شوی.

څه پیښیږي که تاسو ناکافي غوښتل شوي CPU نصب کړئ؟

که کانټینر د نصب کولو څخه ډیر ته اړتیا ولري، دا به د نورو پروسو څخه CPU غلا کړي.

څه پیښیږي که تاسو د CPU حد ډیر ټیټ وټاکئ؟

څرنګه چې د CPU سرچینه د تنظیم وړ ده، تروتلینګ به فعال شي.

څه پیښیږي که تاسو د CPU غوښتنه مشخص نه کړئ؟

د حافظې په څیر، د غوښتنې ارزښت د حد سره مساوي دی.

څه پیښیږي که تاسو د CPU حد مشخص نه کړئ؟

کانټینر به څومره CPU وکاروي څومره چې ورته اړتیا وي. که چیرې د ډیفالټ CPU پالیسي (LimitRange) په نوم ځای کې تعریف شي ، نو دا حد د کانټینر لپاره هم کارول کیږي.

څه پیښیږي که تاسو د غوښتنې یا CPU حد مشخص نه کړئ؟

لکه څنګه چې د حافظې سره، دا ترټولو ناوړه قضیه ده. مهالویش کوونکی نه پوهیږي چې ستاسو کانټینر څومره سرچینو ته اړتیا لري، او دا کولی شي په نوډ کې جدي ستونزې رامینځته کړي. د دې څخه د مخنیوي لپاره، تاسو اړتیا لرئ چې د نوم ځایونو لپاره ډیفالټ حدونه وټاکئ (LimitRange).

په یاد ولرئ: که تاسو د نوډونو چمتو کولو څخه د ډیر CPU غوښتنه وکړئ ، پوډ به مهالویش نه وي. Requests.cpu - لږترلږه ارزښت نه، مګر د پوډ پیل کولو لپاره کافي ارزښت او پرته له ناکامۍ کار کوي. که چیرې غوښتنلیک پیچلې محاسبې ترسره نکړي، غوره انتخاب د نصبولو لپاره دی request.cpu <= 1 او د اړتیا په صورت کې ډیری نقلونه پیل کړئ.

د غوښتل شوي سرچینو مثالی مقدار یا د سرچینو حد

موږ د کمپیوټري سرچینو محدودیت په اړه زده کړل. اوس دا وخت دی چې دې پوښتنې ته ځواب ووایاست: "زما پوډ څومره سرچینې ته اړتیا لري پرته له کومې ستونزې غوښتنلیک چلولو لپاره؟ مثالی مقدار څه شی دی؟

له بده مرغه، دغو پوښتنو ته روښانه ځوابونه شتون نلري. که تاسو نه پوهیږئ چې ستاسو غوښتنلیک څنګه کار کوي یا څومره CPU یا حافظې ته اړتیا لري، غوره اختیار دا دی چې غوښتنلیک ته ډیره حافظه او CPU ورکړئ او بیا د فعالیت ازموینې ترسره کړئ.

د فعالیت ازموینې سربیره، د یوې اونۍ لپاره په نظارت کې د غوښتنلیک چلند وڅیړئ. که ګرافونه ښیي چې ستاسو غوښتنلیک ستاسو د غوښتنې په پرتله لږ سرچینې مصرفوي، تاسو کولی شئ د غوښتل شوي CPU یا حافظې مقدار کم کړئ.

د مثال په توګه دا وګورئ د ګرافانا ډشبورډ. دا د غوښتل شوي منابعو یا د منابعو محدودیت او د اوسنۍ سرچینې کارولو ترمنځ توپیر ښیې.

پایلې

د سرچینو غوښتنه کول او محدودول ستاسو د کوبرنیټس کلستر صحتمند ساتلو کې مرسته کوي. د مناسب حد ترتیب لګښتونه کموي او غوښتنلیکونه هر وخت روان ساتي.

په لنډه توګه، په ذهن کې ساتلو لپاره یو څو شیان شتون لري:

  1. غوښتل شوي سرچینې یو ترتیب دی چې د پیل په وخت کې په پام کې نیول کیږي (کله چې کوبرنیټس د غوښتنلیک کوربه کولو پلان لري). برعکس، د منابعو محدودول د چلولو په وخت کې مهم دي - کله چې غوښتنلیک دمخه په نوډ کې روان وي.
  2. د حافظې په پرتله، CPU یوه منظمه سرچینه ده. که چیرې کافي CPU شتون ونلري ، نو ستاسو پوډ به بند نشي او د تختولو میکانیزم به فعال شي.
  3. غوښتل شوي سرچینې او د سرچینو حد لږترلږه او اعظمي ارزښت نلري! د غوښتل شوي سرچینو په ټاکلو سره، تاسو ډاډه یاست چې غوښتنلیک به پرته له کومې ستونزې پرمخ ځي.
  4. یو ښه عمل دا دی چې د حافظې غوښتنه د حافظې حد سره مساوي تنظیم کړئ.
  5. سمه ده د نصبولو غوښتنه شوې CPU <=1، که چیرې غوښتنلیک پیچلې محاسبې ترسره نکړي.
  6. که تاسو په نوډ کې د شتون په پرتله د ډیرو سرچینو غوښتنه وکړئ ، نو پوډ به هیڅکله دې نوډ ته ونه ټاکل شي.
  7. د غوښتل شوي منابعو / منابعو محدودیتونو سم مقدار ټاکلو لپاره، د بار ازموینې او نظارت څخه کار واخلئ.

زه امید لرم چې دا مقاله تاسو سره د سرچینو محدودیت لومړني مفهوم په پوهیدو کې مرسته کوي. او تاسو به وکولی شئ دا پوهه په خپل کار کې پلي کړئ.

ښه چانس!

نور څه ولولئ:

  1. د SRE مشاهده: نوم ځایونه او میټریک جوړښت.
  2. د کبرنیټس لپاره 90+ ګټورې وسیلې: ځای په ځای کول، مدیریت، څارنه، امنیت او نور ډیر څه.
  3. زموږ چینل په ټیلیګرام کې د کوبرنیټس شاوخوا.

سرچینه: www.habr.com

Add a comment