CPU کی حدیں اور Kubernetes میں جارحانہ تھروٹلنگ

نوٹ. ترجمہ: Omio کی یہ احتیاطی کہانی، یورپی ٹریول ایگریگیٹر، قارئین کو بنیادی تھیوری سے Kubernetes کی ترتیب کی دلچسپ عملی پیچیدگیوں تک لے جاتی ہے۔ ایسے معاملات سے واقفیت نہ صرف اپنے افق کو وسیع کرنے میں مدد دیتی ہے بلکہ غیر معمولی مسائل کو روکنے میں بھی مدد دیتی ہے۔

کیا آپ کو کبھی اس حقیقت کا سامنا کرنا پڑا ہے کہ ایپلیکیشن اپنی جگہ پر "پھنسی" ہے، صحت کی جانچ کی درخواستوں کا جواب دینا بند کر دیا ہے اور آپ اس رویے کی وجہ نہیں سمجھ سکے ہیں؟ ایک ممکنہ وضاحت CPU وسائل پر کوٹہ کی حد سے متعلق ہے۔ اس پر اس مضمون میں بحث کی جائے گی۔

TL؛ ڈاکٹر:
اگر سی ایف ایس کوٹہ کی خرابی کے ساتھ لینکس کرنل کا ورژن استعمال کر رہے ہیں تو ہم Kubernetes (یا Kubelet میں CFS کوٹہ کو غیر فعال کرنے) میں CPU کی حدود کو غیر فعال کرنے کی انتہائی سفارش کرتے ہیں۔ اصل میں دستیاب ہے۔ سنجیدہ اور اچھی طرح سے جانا جاتا ہے ایک بگ جو ضرورت سے زیادہ تھروٹلنگ اور تاخیر کا باعث بنتا ہے۔.

اومیو میں پورے انفراسٹرکچر کا انتظام Kubernetes کے ذریعے کیا جاتا ہے۔. ہمارے تمام ریاستی اور بے وطن کام کا بوجھ خصوصی طور پر Kubernetes پر چلتا ہے (ہم Google Kubernetes انجن استعمال کرتے ہیں)۔ پچھلے چھ مہینوں میں، ہم نے بے ترتیب سست روی کا مشاہدہ کرنا شروع کیا۔ درخواستیں منجمد ہو جاتی ہیں یا صحت کی جانچ کا جواب دینا بند کر دیتی ہیں، نیٹ ورک کنکشن کھو دیتی ہیں، وغیرہ۔ اس طرح کے رویے نے ہمیں ایک طویل عرصے تک حیران کیا، اور آخر کار، ہم نے سنجیدگی سے اس مسئلے سے نمٹنے کا فیصلہ کیا۔

مضمون کا خلاصہ:

• کنٹینرز اور Kubernetes کے بارے میں چند الفاظ؛
• سی پی یو کی درخواستوں اور حدود کو کیسے نافذ کیا جاتا ہے۔
• ملٹی کور ماحول میں CPU کی حد کیسے کام کرتی ہے۔
• سی پی یو تھروٹلنگ کو کیسے ٹریک کریں؛
• مسائل کا حل اور تفصیلات۔

کنٹینرز اور کبرنیٹس کے بارے میں چند الفاظ

Kubernetes بنیادی طور پر بنیادی ڈھانچے کی دنیا میں جدید معیار ہے۔ اس کا بنیادی کام کنٹینر آرکیسٹریشن ہے۔

کنٹینرز

ماضی میں، ہمیں سرورز پر چلانے کے لیے جاوا JARs/WARs، ​​Python Eggs، یا executables جیسے نمونے بنانے پڑتے تھے۔ تاہم، انہیں کام کرنے کے لیے، آپ کو اضافی کام کرنا پڑا: رن ٹائم (جاوا/پائیتھون) انسٹال کریں، ضروری فائلوں کو صحیح جگہ پر رکھیں، آپریٹنگ سسٹم کے کسی خاص ورژن کے ساتھ مطابقت کو یقینی بنائیں، وغیرہ۔ دوسرے لفظوں میں، آپ کو کنفیگریشن مینجمنٹ پر پوری توجہ دینی پڑتی تھی (جو اکثر ڈویلپرز اور سسٹم ایڈمنسٹریٹرز کے درمیان تنازعہ کا باعث بنتا تھا)۔

کنٹینرز نے سب کچھ بدل دیا ہے۔ اب کنٹینر کی تصویر آرٹفیکٹ ہے۔ اسے ایک قسم کی توسیعی ایگزیکیوٹیبل فائل کے طور پر پیش کیا جا سکتا ہے جس میں نہ صرف پروگرام، بلکہ ایک مکمل رن ٹائم ماحول (جاوا/پائیتھون/...) کے ساتھ ساتھ ضروری فائلز/پیکیجز، پہلے سے انسٹال اور چلانے کے لیے تیار ہوں۔ کنٹینرز کو بغیر کسی اضافی اقدامات کے مختلف سرورز پر تعینات اور چلایا جا سکتا ہے۔

اس کے علاوہ، کنٹینرز اپنے سینڈ باکس کے ماحول میں چلتے ہیں۔ ان کے پاس اپنا ورچوئل نیٹ ورک اڈاپٹر ہے، محدود رسائی کے ساتھ ان کا اپنا فائل سسٹم، ان کا اپنا پروسیس ہائرارکی، سی پی یو اور میموری پر ان کی اپنی پابندیاں، وغیرہ۔ یہ سب لینکس کرنل کے ایک خاص سب سسٹم کی بدولت لاگو ہوتا ہے - نام کی جگہیں (نیم اسپیس)۔

Kubernetes

جیسا کہ پہلے ذکر کیا گیا ہے، Kubernetes ایک کنٹینر آرکیسٹریٹر ہے۔ یہ اس طرح کام کرتا ہے: آپ اسے مشینوں کا ایک تالاب دیتے ہیں، اور پھر آپ کہتے ہیں، "ارے کبرنیٹس، میرے کنٹینر کی دس مثالیں 2 پروسیسرز اور 3 جی بی میموری کے ساتھ چلائیں، اور انہیں چلاتے رہیں!"۔ Kubernetes باقی کا خیال رکھیں گے۔ یہ مفت صلاحیتوں کو تلاش کرے گا، کنٹینرز کو لانچ کرے گا اور اگر ضروری ہو تو انہیں دوبارہ شروع کرے گا، ورژن تبدیل کرتے وقت ایک اپ ڈیٹ رول آؤٹ کرے گا، وغیرہ۔ جوہر میں، Kubernetes آپ کو ہارڈ ویئر سے خلاصہ کرنے کی اجازت دیتا ہے اور تمام قسم کے سسٹمز کو ایپلی کیشنز کی تعیناتی اور چلانے کے لیے موزوں بناتا ہے۔

ایک عام آدمی کے نقطہ نظر سے Kubernetes

Kubernetes میں درخواستیں اور حدود کیا ہیں؟

ٹھیک ہے، ہم نے کنٹینرز اور کبرنیٹس کا پتہ لگایا۔ ہم یہ بھی جانتے ہیں کہ ایک ہی مشین پر متعدد کنٹینرز رہ سکتے ہیں۔

آپ فرقہ وارانہ اپارٹمنٹ کے ساتھ مشابہت کھینچ سکتے ہیں۔ ایک کشادہ کمرہ (کاریں/اسمبلیاں) لیا جاتا ہے اور کئی کرایہ داروں (کنٹینرز) کو کرائے پر دیا جاتا ہے۔ Kubernetes ایک ریئلٹر کے طور پر کام کرتا ہے۔ سوال یہ پیدا ہوتا ہے کہ کرایہ داروں کو ایک دوسرے کے ساتھ تنازعات سے کیسے بچایا جائے؟ کیا ہوگا اگر ان میں سے کوئی، کہے، آدھے دن کے لیے باتھ روم لینے کا فیصلہ کرے؟

یہ وہ جگہ ہے جہاں درخواستیں اور حدود کھیل میں آتی ہیں۔ سی پی یو کی درخواست صرف منصوبہ بندی کے مقاصد کے لیے درکار ہے۔ یہ کنٹینر کی "خواہش کی فہرست" کی طرح ہے، اور سب سے موزوں نوڈ کو منتخب کرنے کے لیے استعمال کیا جاتا ہے۔ ایک ہی وقت میں، CPU محدود لیز کے معاہدے سے موازنہ کیا جا سکتا ہے - جیسے ہی ہم کنٹینر کے لیے نوڈ منتخب کرتے ہیں، وہ نہیں کر سکتے حد سے باہر جاؤ. اور یہاں مسئلہ آتا ہے ...

کبرنیٹس میں درخواستوں اور حدود کو کیسے نافذ کیا جاتا ہے۔

Kubernetes CPU کی حدود کو نافذ کرنے کے لیے کرنل میں بنایا ہوا تھروٹلنگ میکانزم (کلاک اسکیپنگ) استعمال کرتا ہے۔ اگر ایپلیکیشن حد سے بڑھ جاتی ہے، تو تھروٹلنگ فعال ہو جاتی ہے (یعنی اسے کم CPU سائیکل ملتے ہیں)۔ یادداشت کی درخواستوں اور حدود کو مختلف طریقے سے ترتیب دیا گیا ہے تاکہ ان کا پتہ لگانا آسان ہو۔ ایسا کرنے کے لیے، پوڈ کی آخری ری اسٹارٹ اسٹیٹس کو چیک کرنا کافی ہے: کیا یہ "OOMKilled" ہے۔ CPU تھروٹلنگ اتنا آسان نہیں ہے، کیونکہ K8s صرف استعمال کے لحاظ سے میٹرکس دستیاب کرتا ہے، cgroups کے ذریعے نہیں۔

سی پی یو کی درخواست

سی پی یو کی درخواست کو کیسے لاگو کیا جاتا ہے۔

سادگی کی خاطر، آئیے 4 کور CPU والی مشین کی مثال کا استعمال کرتے ہوئے عمل کو دیکھیں۔

K8s وسائل کی تقسیم (میموری اور سی پی یو) کو منظم کرنے کے لیے cgroups طریقہ کار کا استعمال کرتا ہے۔ اس کے لیے ایک درجہ بندی کا ماڈل دستیاب ہے: بچہ والدین کے گروپ کی حدود کا وارث ہوتا ہے۔ تقسیم کی تفصیلات ورچوئل فائل سسٹم میں محفوظ ہیں (/sys/fs/cgroup)۔ ایک پروسیسر کے معاملے میں، یہ /sys/fs/cgroup/cpu,cpuacct/*.

K8s فائل استعمال کرتا ہے۔ cpu.share پروسیسر کے وسائل مختص کرنے کے لیے۔ ہمارے معاملے میں، روٹ سی گروپ کو CPU وسائل کے 4096 شیئرز ملتے ہیں - دستیاب پروسیسر پاور کا 100% (1 کور = 1024؛ یہ ایک مقررہ قیمت ہے)۔ جڑ گروپ وسائل کو متناسب طور پر تقسیم کرتا ہے جس میں بیان کردہ اولاد کے حصص پر منحصر ہے۔ cpu.share، اور وہ، بدلے میں، اپنی اولاد کے ساتھ ایسا ہی کرتے ہیں، وغیرہ۔ ایک عام Kubernetes میزبان میں، روٹ سی گروپ کے تین بچے ہوتے ہیں: system.slice, user.slice и kubepods. پہلے دو ذیلی گروپس کا استعمال K8s سے باہر اہم سسٹم بوجھ اور صارف پروگراموں کے درمیان وسائل مختص کرنے کے لیے کیا جاتا ہے۔ آخری - kubepods - پھلیوں کے درمیان وسائل کی تقسیم کے لیے Kubernetes کے ذریعے تخلیق کیا گیا۔

اوپر کا خاکہ ظاہر کرتا ہے کہ پہلا اور دوسرا ذیلی گروپ موصول ہوا۔ 1024 شیئرز، جبکہ kuberpod ذیلی گروپ مختص کیا گیا ہے۔ 4096 شیئرز یہ کیسے ممکن ہے: سب کے بعد، جڑ گروپ کو صرف تک رسائی حاصل ہے 4096 حصص، اور اس کی اولاد کے حصص کا مجموعہ نمایاں طور پر اس تعداد سے زیادہ ہے (6144)؟ نقطہ یہ ہے کہ قدر کا ایک منطقی معنی ہے، لہذا لینکس شیڈیولر (CFS) اسے CPU وسائل کو متناسب طور پر مختص کرنے کے لیے استعمال کرتا ہے۔ ہمارے معاملے میں، پہلے دو گروہ وصول کرتے ہیں۔ 680 حقیقی حصص (16,6 کا 4096%) اور کیوب پوڈ کو باقی ملتا ہے۔ 2736 شیئرز بند ہونے کی صورت میں، پہلے دو گروپ مختص کردہ وسائل استعمال نہیں کریں گے۔

خوش قسمتی سے، شیڈولر کے پاس غیر استعمال شدہ CPU وسائل کو ضائع کرنے سے بچنے کا طریقہ کار ہے۔ یہ "بے کار" صلاحیت کو عالمی تالاب میں منتقل کرتا ہے، جہاں سے اسے ان گروپوں میں تقسیم کیا جاتا ہے جن کو اضافی پروسیسر پاور کی ضرورت ہوتی ہے (گول ہونے والے نقصانات سے بچنے کے لیے یہ منتقلی بیچوں میں ہوتی ہے)۔ یہی طریقہ اولاد کی تمام اولادوں پر لاگو ہوتا ہے۔

یہ طریقہ کار پروسیسر کی طاقت کی منصفانہ تقسیم کو یقینی بناتا ہے اور اس بات کو یقینی بناتا ہے کہ کوئی بھی عمل دوسروں سے وسائل "چوری" نہ کرے۔

سی پی یو کی حد

اگرچہ K8s میں حد اور درخواست کی ترتیب ایک جیسی نظر آتی ہے، لیکن ان کا نفاذ بنیادی طور پر مختلف ہے: سب سے زیادہ گمراہ کن اور کم سے کم دستاویزی حصہ۔

K8s سائیکل CFS کوٹہ میکانزم حدود کو نافذ کرنے کے لئے. ان کی ترتیبات فائلوں میں بیان کی گئی ہیں۔ cfs_period_us и cfs_quota_us cgroup ڈائریکٹری میں (ایک فائل بھی ہے۔ cpu.share).

برعکس cpu.share، کوٹہ پر مبنی ہے۔ وقت کی مدت، اور دستیاب پروسیسر پاور پر نہیں۔ cfs_period_us مدت (ایپوچ) کا دورانیہ بتاتا ہے - یہ ہمیشہ 100000 µs (100 ms) ہوتا ہے۔ اس قدر کو تبدیل کرنے کے لیے K8s میں ایک آپشن موجود ہے، تاہم یہ فی الحال صرف الفا میں دستیاب ہے۔ شیڈیولر استعمال شدہ کوٹوں کو دوبارہ شروع کرنے کے لیے عہد کا استعمال کرتا ہے۔ دوسری فائل، cfs_quota_us، ہر دور میں دستیاب وقت (کوٹہ) کی وضاحت کرتا ہے۔ نوٹ کریں کہ یہ مائیکرو سیکنڈز میں بھی بیان کیا گیا ہے۔ کوٹہ ایک عہد کی لمبائی سے تجاوز کر سکتا ہے۔ دوسرے الفاظ میں، یہ 100 ms سے زیادہ ہو سکتا ہے۔

آئیے 16 کور مشینوں پر دو منظرنامے دیکھیں (ہمارے پاس Omio میں موجود سب سے عام قسم کی مشین):

منظر نامہ 1: 2 تھریڈز اور 200ms کی حد۔ کوئی تھروٹلنگ نہیں۔

منظر نامہ 2: 10 تھریڈز اور 200ms کی حد۔ تھروٹلنگ 20ms کے بعد شروع ہوتی ہے، CPU وسائل تک رسائی مزید 80ms کے بعد دوبارہ شروع ہو جاتی ہے۔

ہم کہتے ہیں کہ آپ نے CPU کی حد مقرر کی ہے۔ 2 دانا Kubernetes اس قدر کو 200ms میں ترجمہ کرے گا۔ اس کا مطلب ہے کہ کنٹینر تھروٹلنگ کے بغیر زیادہ سے زیادہ 200ms CPU وقت استعمال کر سکتا ہے۔

اور یہاں سے مزہ شروع ہوتا ہے۔ جیسا کہ اوپر بتایا گیا ہے، دستیاب کوٹہ 200ms ہے۔ اگر آپ کے پاس متوازی کام ہے۔ دس 12 کور مشین پر تھریڈز (منظرنامہ 2 کی مثال دیکھیں)، جب کہ دیگر تمام پوڈز بیکار ہیں، کوٹہ صرف 20ms میں ختم ہو جائے گا (کیونکہ 10 * 20ms = 200ms)، اور اس پوڈ کے تمام دھاگے لٹک جائیں گے » (گلا گھونٹنا) اگلے 80 ms کے لیے پہلے ہی بیان کیے گئے حالات کی وجہ سے صورتحال مزید گھمبیر ہے۔ شیڈولر بگ، جس کی وجہ سے ضرورت سے زیادہ تھروٹلنگ ہوتی ہے اور کنٹینر موجودہ کوٹہ کو بھی پورا نہیں کرسکتا۔

پھلیوں میں تھروٹلنگ کا اندازہ کیسے کریں؟

بس پوڈ میں لاگ ان کریں اور کریں۔ 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 فیصد

آپریٹنگ اخراجات

مثال کے طور پر گزارے گئے گھنٹوں کی تعداد

کیچ کیا ہے؟

جیسا کہ مضمون کے آغاز میں کہا گیا ہے:

آپ فرقہ وارانہ اپارٹمنٹ کے ساتھ مشابہت کھینچ سکتے ہیں ... Kubernetes ایک ریئلٹر کے طور پر کام کرتا ہے۔ لیکن کرایہ داروں کو ایک دوسرے کے ساتھ تنازعات سے کیسے بچایا جائے؟ کیا ہوگا اگر ان میں سے کوئی، کہے، آدھے دن کے لیے باتھ روم لینے کا فیصلہ کرے؟

یہ رہا کیچ۔ ایک لاپرواہ کنٹینر مشین پر دستیاب CPU کے تمام وسائل استعمال کر سکتا ہے۔ اگر آپ کے پاس ایک سمارٹ ایپلیکیشن اسٹیک ہے (مثال کے طور پر، JVM، Go، Node VM کو مناسب طریقے سے ترتیب دیا گیا ہے)، تو یہ کوئی مسئلہ نہیں ہے: آپ اس طرح کے حالات میں طویل عرصے تک کام کر سکتے ہیں۔ لیکن اگر ایپلی کیشنز ناقص طور پر آپٹمائزڈ ہیں یا بالکل بھی آپٹمائز نہیں ہیں (FROM java:latest)، صورتحال قابو سے باہر ہو سکتی ہے۔ Omio میں، ہمارے پاس بنیادی زبان کے اسٹیک کے لیے کافی ڈیفالٹس کے ساتھ خودکار بیس Dockerfiles ہیں، اس لیے یہ مسئلہ موجود نہیں تھا۔

ہم میٹرکس کی نگرانی کی تجویز کرتے ہیں۔ کے لئے استعمال کریں (استعمال، سنترپتی، اور غلطیاں)، API میں تاخیر، اور خرابی کی شرح۔ یقینی بنائیں کہ نتائج آپ کی توقعات کے مطابق ہیں۔

حوالہ جات

یہ ہماری تاریخ ہے۔ مندرجہ ذیل مواد نے یہ سمجھنے میں بہت مدد کی کہ کیا ہو رہا ہے:

• kernel.org → CFS شیڈولر;
• kernel.org → CFS بینڈوتھ کنٹرول;
• لینکس کنٹینر شیڈولنگ کو سمجھنا;
• لینکس کنٹینرز کے بارے میں آپ کو جاننے کے لیے ہر چیز کی ضرورت ہے، حصہ I: لینکس کنٹرول گروپس اور عمل تنہائی;
• کبرنیٹس کی ناکامی کی کہانیاں - "cpu تھروٹلنگ" تلاش کریں۔

Kubernetes بگ رپورٹس:

• #51135: گارنٹی شدہ پوڈز کے لیے سی پی یو کی حد مقرر کرنے سے گریز کریں۔;
• #67577: CFS کوٹہ غیر ضروری تھروٹلنگ کا باعث بن سکتا ہے۔;
• حد سے زیادہ جارحانہ CFS.

کیا آپ کو اپنی مشق میں اسی طرح کے مسائل کا سامنا کرنا پڑا ہے یا کنٹینرائزڈ پروڈکشن ماحول میں تھروٹلنگ سے متعلق تجربہ ہے؟ تبصرے میں اپنی کہانی کا اشتراک کریں!

مترجم سے PS

ہمارے بلاگ پر بھی پڑھیں:

• «Kubernetes میں آٹو اسکیلنگ اور وسائل کا انتظام (جائزہ اور ویڈیو رپورٹ)؛ "
• «کبرنیٹس میں سی پی یو مینیجر کیسے کام کرتا ہے۔؛ "
• «جب آپ kubectl رن چلاتے ہیں تو Kubernetes میں کیا ہوتا ہے؟ حصہ 2'.

ماخذ: www.habr.com