په کبرنیټس کې د CPU محدودیتونه او تیري کوونکی

نوټ. ژباړه: د Omio دا د سترګو پرانیستی تاریخ - د اروپا د سفر راټولونکی - لوستونکي د بنسټیز تیوري څخه د کوبرنیټس ترتیب په زړه پورې عملي پیچلتیاو ته لیږي. د داسې قضیو پیژندنه نه یوازې ستاسو افق پراخه کولو کې مرسته کوي ، بلکه د غیر معمولي ستونزو مخه هم نیسي.

ایا تاسو کله هم یو غوښتنلیک په ځای کې پاتې راغلی، د روغتیا چکونو ته ځواب ویل بند کړئ، او د دې توان نه لرئ چې معلومه کړئ ولې؟ یو احتمالي توضیح د CPU سرچینو کوټې محدودیتونو پورې اړه لري. دا هغه څه دي چې موږ به پدې مقاله کې خبرې وکړو.

د تمديد؛ DR:
موږ په کلکه سپارښتنه کوو چې په کبرنیټس کې د CPU محدودیتونه غیر فعال کړئ (یا په کوبیلیټ کې د CFS کوټې غیر فعال کړئ) که تاسو د CFS کوټې بګ سره د لینکس کرنل نسخه کاروئ. په کور کې شتون لري جدي او ښه پیژندل شوی یوه بګ چې د ډیر فشار او ځنډ لامل کیږي.

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

د مقالې لنډیز:

• د کانټینرونو او کبرنیټس په اړه یو څو خبرې؛
• د CPU غوښتنې او حدود څنګه پلي کیږي؛
• د CPU محدودیت څنګه په څو کور چاپیریال کې کار کوي؛
• د CPU تروټلینګ څنګه تعقیب کړئ؛
• د ستونزې حل او لنډیز.

د کانټینرونو او کبرنیټس په اړه یو څو خبرې

Kubernetes اساسا د زیربنا نړۍ کې عصري معیار دی. د دې اصلي دنده د کانټینر آرکیسټریشن دی.

کانټینرونه

په تیرو وختونو کې، موږ باید د جاوا JARs/WARs، ​​Python Eggs، یا په سرورونو کې د چلولو لپاره د اجرا وړ اثار جوړ کړي. په هرصورت، د دوی د فعالیت کولو لپاره، اضافي کار باید ترسره شي: د چلولو چاپیریال (جاوا/پایتون) نصب کول، په سم ځایونو کې د اړین فایلونو ځای په ځای کول، د عملیاتي سیسټم ځانګړي نسخه سره مطابقت یقیني کول، او نور. په بل عبارت، د تشکیلاتو مدیریت ته باید د پام وړ پاملرنه وشي (کوم چې ډیری وختونه د پراختیا کونکو او سیسټم مدیرانو ترمنځ د شخړې سرچینه وه).

کانټینر هر څه بدل کړل. اوس اثار د کانټینر عکس دی. دا د یو ډول غزیدلي اجرا وړ فایل په توګه ښودل کیدی شي چې نه یوازې برنامه لري ، بلکه د بشپړ اجرا کولو چاپیریال (جاوا/پایتون/...) هم لري ، او همدارنګه اړین فایلونه / کڅوړې ، دمخه نصب شوي او چمتو دي. منډې کانټینرونه ځای په ځای کیدی شي او پرته له کوم اضافي مرحلو څخه په مختلف سرورونو کې چلول کیدی شي.

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

کوبنیټس

لکه څنګه چې مخکې وویل شول، Kubernetes یو کانټینر آرکیسټرټر دی. دا د دې په څیر کار کوي: تاسو دې ته د ماشینونو حوض ورکړئ، او بیا ووایاست: "ای، کوبرنیټس، راځئ چې زما د کانټینر لس مثالونه د 2 پروسیسرونو او 3 GB حافظې سره پیل کړو، او دوی یې روان وساتئ!" Kubernetes به پاتې پاملرنه وکړي. دا به وړیا ظرفیت ومومي ، کانټینرونه لانچ کړي او د اړتیا په صورت کې یې بیا پیل کړي ، د نسخو بدلولو پرمهال تازه معلومات راوباسي ، او داسې نور. په لازمي ډول ، Kubernetes تاسو ته اجازه درکوي د هارډویر اجزا خلاص کړئ او د غوښتنلیکونو پلي کولو او چلولو لپاره مناسب سیسټمونه پراخه ډولونه رامینځته کوي.

Kubernetes د عامو خلکو له نظره

په Kubernetes کې غوښتنې او حدود څه دي

ښه، موږ کانټینرونه او کبرنیټ پوښلي دي. موږ دا هم پوهیږو چې ډیری کانټینرونه په ورته ماشین کې پاتې کیدی شي.

یو مشابهت د ټولنیز اپارتمان سره رسم کیدی شي. یو پراخه ځای (ماشینونه / واحدونه) اخیستل کیږي او څو کرایه کونکو (کانټینرونو) ته په کرایه ورکول کیږي. Kubernetes د حقیقي په توګه کار کوي. پوښتنه دا پیدا کیږي چې کرایه کونکي څنګه له یو بل سره د شخړو څخه ساتل کیږي؟ که چیرې یو له دوی څخه ووایی، پریکړه وکړي چې د نیمې ورځې لپاره تشناب په پور واخلي؟

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

په کبرنیټس کې غوښتنې او محدودیتونه څنګه پلي کیږي

Kubernetes د CPU محدودیتونو پلي کولو لپاره په کرنل کې جوړ شوی د ټروټلینګ میکانیزم (د ساعت دورې پریښودل) کاروي. که چیرې یو غوښتنلیک له حد څخه تیر شي، تروتلینګ فعال شوی (د بیلګې په توګه دا د CPU لږ دورې ترلاسه کوي). د حافظې لپاره غوښتنې او محدودیتونه په مختلف ډول تنظیم شوي ، نو دوی موندل اسانه دي. د دې کولو لپاره، یوازې د پوډ وروستی بیا پیل حالت وګورئ: ایا دا "OOMKilled" ده. د CPU throttling دومره ساده نده، ځکه چې K8s یوازې د کارونې له مخې میټریکونه چمتو کوي، نه د cgroups لخوا.

د CPU غوښتنه

د CPU غوښتنه څنګه پلي کیږي

د سادګۍ لپاره ، راځئ چې د مثال په توګه د 4 کور CPU سره د ماشین کارولو پروسې ته وګورو.

K8s د کنټرول ګروپ میکانیزم (cgroups) کاروي ترڅو د سرچینو تخصیص کنټرول کړي (یاد او پروسیسر). د دې لپاره یو درجه بندي ماډل شتون لري: ماشوم د مور او پلار د ډلې حدود میراث کوي. د توزیع توضیحات په مجازی فایل سیسټم کې زیرمه شوي (/sys/fs/cgroup). د پروسیسر په قضیه کې دا دی /sys/fs/cgroup/cpu,cpuacct/*.

K8s فایل کاروي cpu.share د پروسیسر سرچینې تخصیص کول. زموږ په قضیه کې، د روټ cgroup د CPU سرچینو 4096 ونډې ترلاسه کوي - د موجود پروسیسر ځواک 100٪ (1 کور = 1024؛ دا یو ثابت ارزښت دی). د ریښې ګروپ سرچینې په متناسب ډول د راجسټر شوي اولادونو ونډې پورې اړه لري cpu.share، او دوی، په بدل کې، د خپلو اولادونو سره ورته کوي، او داسې نور. په یو عادي کوبرنیټس نوډ کې، د ریښې cgroup درې ماشومان لري: system.slice, user.slice и kubepods. لومړی دوه فرعي ګروپونه د K8s څخه بهر د مهم سیسټم بارونو او کارونکي برنامو ترمینځ د سرچینو ویشلو لپاره کارول کیږي. وروستی - kubepods - د کوبرنیټس لخوا رامینځته شوی ترڅو د پوډونو ترمینځ سرچینې توزیع کړي.

پورته انځور ښیي چې لومړی او دویم فرعي ګروپ هر یو ترلاسه کړی 1024 ونډې، د kuberpod فرعي ګروپ سره تخصیص شوي 4096 ونډې دا څنګه ممکنه ده: په هرصورت، د ریښی ګروپ یوازې لاسرسی لري 4096 ونډې، او د هغې د اولادونو د ونډو مجموعه د پام وړ له دې شمیر څخه زیاته ده (6144)؟ ټکی دا دی چې ارزښت منطقي معنی لري، نو د لینکس مهالویش (CFS) دا د CPU سرچینې په تناسب تخصیص کولو لپاره کاروي. زموږ په قضیه کې، لومړی دوه ګروپونه ترلاسه کوي 680 اصلي ونډې (د 16,6 4096٪)، او کوبیپډ پاتې برخه ترلاسه کوي 2736 ونډې د ځنډیدو په صورت کې، لومړۍ دوه ډلې به تخصیص شوي سرچینې ونه کاروي.

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

دا میکانیزم د پروسیسر ځواک عادلانه ویش تضمینوي او ډاډ ورکوي چې هیڅوک د نورو څخه سرچینې "غلا" نه کوي.

د CPU حد

د دې حقیقت سره سره چې په K8s کې د محدودیتونو او غوښتنو ترتیبونه ورته ښکاري، د دوی پلي کول خورا توپیر لري: دا تر ټولو ګمراه کوونکی او لږترلږه مستند برخه.

K8s ښکیل دي د CFS کوټې میکانیزم محدودیتونه پلي کول. د دوی ترتیبات په فایلونو کې مشخص شوي cfs_period_us и cfs_quota_us په cgroup لارښود کې (دوتنه هم هلته موقعیت لري cpu.share).

برعکس cpu.share، کوټه پر بنسټ ولاړه ده د وخت موده، او نه د شته پروسیسر بریښنا باندې. cfs_period_us د دورې موده (epoch) مشخصوي - دا تل 100000 μs (100 ms) وي. په K8s کې د دې ارزښت بدلولو اختیار شتون لري، مګر دا د اوس لپاره یوازې په الفا کې شتون لري. مهالویش کوونکی د کارول شوي کوټو بیا پیلولو لپاره د وخت څخه کار اخلي. دوهم فایل cfs_quota_us، په هر دور کې موجود وخت (کوټه) مشخصوي. په یاد ولرئ چې دا په مایکرو ثانیو کې هم مشخص شوی. کوټه ممکن د دورې اوږدوالي څخه زیاته وي؛ په بل عبارت، دا ممکن د 100 ms څخه ډیر وي.

راځئ چې په 16 کور ماشینونو کې دوه سناریوګانې وګورو (د کمپیوټر ترټولو عام ډول چې موږ یې په Omio کې لرو):

سناریو 1: 2 تارونه او د 200 ms حد. نه throttling

سناریو 2: 10 تارونه او 200 ms حد. د 20 ms وروسته پیل کیږي، د پروسیسر سرچینو ته لاسرسی د نورو 80 ms وروسته بیا پیل کیږي

راځئ چې ووایو تاسو د CPU حد ټاکلی 2 دانه Kubernetes به دا ارزښت 200 ms ته وژباړي. دا پدې مانا ده چې کانټینر کولی شي د throttling پرته د CPU وخت اعظمي 200ms وکاروي.

او دا هغه ځای دی چې تفریح ​​​​پیل کیږي. لکه څنګه چې پورته یادونه وشوه، شته کوټه 200 ms ده. که تاسو په موازي توګه کار کوئ لس په 12 کور ماشین کې تارونه (د سناریو 2 لپاره مثال وګورئ)، پداسې حال کې چې نور ټول پوډونه بې کاره دي، کوټه به یوازې په 20 ms کې ختمه شي (له 10 * 20 ms = 200 ms څخه)، او د دې پوډ ټولې تارونه به ځړول شي. » (ګوتې) د راتلونکو 80 ms لپاره. مخکې ذکر شوي مهالویش کوونکی بګ، چې له امله یې ډیر درول کیږي او کانټینر حتی نشي کولی موجوده کوټه پوره کړي.

په پوډونو کې د throttling ارزونه څنګه؟

یوازې پوډ ته ننوتل او اجرا یې کړئ cat /sys/fs/cgroup/cpu/cpu.stat.

• nr_periods - د مهالویش ټولیز شمیر؛
• nr_throttled - په ترکیب کې د غلچکی دورې شمیر nr_periods;
• throttled_time - په نانو ثانوي کې د ډلبندۍ وخت.

رښتیا څه روان دي؟

د پایلې په توګه، موږ په ټولو غوښتنلیکونو کې لوړ فشار ترلاسه کوو. کله کله هغه دننه وي یو نیم ځل له محاسبې څخه قوي!

دا د مختلف غلطیو لامل کیږي - د چمتووالي چک ناکامي ، کانټینر کنګل کول ، د شبکې اتصال ماتول ، د خدماتو تلیفونونو کې وخت پای. دا په نهایت کې د ځنډ او لوړې خطا نرخونو پایله کوي.

پریکړه او پایلې

دلته هرڅه ساده دي. موږ د CPU محدودیتونه پریښودل او وروستي نسخه ته مو په کلسترونو کې د OS کرنل تازه کول پیل کړل، په کوم کې چې بګ فکس شوی و. زموږ په خدماتو کې د غلطیو شمیر (HTTP 5xx) سمدلاسه د پام وړ راټیټ شو:

د HTTP 5xx تېروتنې

د یو مهم خدمت لپاره HTTP 5xx غلطۍ

د ځواب وخت p95

د جدي خدماتو غوښتنې ځنډ، 95 فیصده

عملیاتي لګښتونه

د مثال په توګه د مصرف شوي ساعتونو شمیر

نیول څه شی دی؟

لکه څنګه چې د مقالې په پیل کې ویل شوي:

یو مشابهت د ټولنیز اپارتمان سره رسم کیدی شي ... کوبرنیټس د ریالټر په توګه کار کوي. مګر څنګه کرایه کونکي د یو بل سره د شخړو څخه ساتل کیږي؟ که چیرې یو له دوی څخه ووایی، پریکړه وکړي چې د نیمې ورځې لپاره تشناب په پور واخلي؟

دلته کیچ دی. یو بې پروا کانټینر کولی شي په ماشین کې د CPU ټولې موجودې سرچینې وخوري. که تاسو د سمارټ غوښتنلیک سټیک لرئ (د مثال په توګه ، JVM ، Go ، نوډ VM په سمه توګه تنظیم شوی) ، نو دا کومه ستونزه نده: تاسو کولی شئ په داسې شرایطو کې د اوږدې مودې لپاره کار وکړئ. مګر که غوښتنلیکونه په کمزوري ډول اصلاح شوي وي یا په بشپړ ډول مطلوب ندي (FROM java:latest)، کیدای شي وضعیت د کنټرول څخه بهر شي. په اومیو کې موږ د لوی ژبې سټیک لپاره د کافي ډیفالټ ترتیباتو سره اتومات بیس ډاکر فایلونه لرو ، نو دا مسله شتون نلري.

موږ د میټریکونو څارنه وړاندیز کوو USE (استعمال، سنتریت او تېروتنې)، د API ځنډ او د تېروتنې نرخونه. ډاډ ترلاسه کړئ چې پایلې تمه لري.

مرجع

دا زموږ کیسه ده. لاندې موادو ډیره مرسته وکړه چې پوه شي چې څه پیښیږي:

• kernel.org → CFS مهالویش کونکی;
• kernel.org → CFS بانډ ویت کنټرول;
• د لینکس کانټینر مهالویش پوهیدل;
• هرڅه چې تاسو اړتیا لرئ د لینکس کانټینرونو په اړه پوه شئ ، لومړۍ برخه: د لینکس کنټرول ګروپونه او د پروسې جلا کول;
• د کوبرنیټس ناکامۍ کیسې - د "cpu throttling" لپاره وګورئ.

Kubernetes بګ راپور ورکوي:

• #51135: د تضمین پوډونو لپاره د CPU محدودیتونو تنظیم کولو څخه ډډه وکړئ;
• #67577: د CFS کوټې کولی شي د غیر ضروري فشار لامل شي;
• ډیر تیریدونکی CFS.

ایا تاسو په خپل تمرین کې ورته ستونزې سره مخ شوي یاست یا د کانټینر شوي تولید چاپیریال کې د تختولو پورې اړوند تجربه لرئ؟ خپله کیسه په نظرونو کې شریکه کړئ!

PS د ژباړونکي څخه

زموږ په بلاګ کې هم ولولئ:

• «په کبرنیټس کې د اتوماتیک کولو او سرچینو مدیریت (بیاکتنه او ویډیو راپور)»
• «څنګه د CPU مدیر په کوبرنیټس کې کار کوي»
• «په Kubernetes کې څه پیښیږي کله چې تاسو د کیوبیکیل چلول کوئ؟ 2 برخه".

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