2016 میں واپس ہم بفر پر ہیں۔ ، اور اب تقریباً 60 نوڈس (AWS پر) اور 1500 کنٹینرز ہمارے k8s کلسٹر پر کام کر رہے ہیں . تاہم، ہم ٹرائل اور ایرر کے ذریعے مائیکرو سروسز میں چلے گئے، اور k8s کے ساتھ کام کرنے کے کئی سال بعد بھی ہمیں نئی پریشانیوں کا سامنا ہے۔ اس پوسٹ میں ہم بات کریں گے۔ پروسیسر کی حدود: ہم نے کیوں سوچا کہ وہ اچھی پریکٹس ہیں اور آخر وہ اتنے اچھے کیوں نہیں ہیں۔
پروسیسر کی حدود اور تھروٹلنگ
بہت سے دوسرے Kubernetes صارفین کی طرح، . ایسی ترتیب کے بغیر، نوڈ میں موجود کنٹینرز پروسیسر کی تمام طاقت لے سکتے ہیں، جس کے نتیجے میں کبرنیٹس کے اہم عمل ہوتے ہیں (مثال کے طور پر kubelet) درخواستوں کا جواب دینا بند کر دے گا۔ اس طرح، سی پی یو کی حدود کا تعین آپ کے نوڈس کی حفاظت کا ایک اچھا طریقہ ہے۔
پروسیسر کی حدیں ایک کنٹینر کو زیادہ سے زیادہ CPU وقت پر سیٹ کرتی ہیں جو اسے ایک مخصوص مدت کے لیے استعمال کر سکتا ہے (پہلے سے طے شدہ 100ms ہے)، اور کنٹینر کبھی بھی اس حد سے تجاوز نہیں کرے گا۔ کے لئے Kubernetes میں تھروٹلنگ کنٹینر اور اسے حد سے تجاوز کرنے سے روکنے کے لیے، ایک خاص ٹول استعمال کیا جاتا ہے۔ ، لیکن یہ مصنوعی CPU حدود کارکردگی کو نقصان پہنچاتی ہیں اور آپ کے کنٹینرز کے رسپانس ٹائم میں اضافہ کرتی ہیں۔
اگر ہم پروسیسر کی حدود متعین نہیں کرتے ہیں تو کیا ہو سکتا ہے؟
بدقسمتی سے ہمیں خود اس مسئلے کا سامنا کرنا پڑا۔ ہر نوڈ میں ایک عمل ہوتا ہے جو کنٹینرز کے انتظام کے لیے ذمہ دار ہوتا ہے۔ kubelet، اور اس نے درخواستوں کا جواب دینا چھوڑ دیا۔ نوڈ، جب ایسا ہوتا ہے، ریاست میں جائے گا NotReady، اور اس سے کنٹینرز کو کہیں اور ری ڈائریکٹ کیا جائے گا اور نئے نوڈس پر وہی مسائل پیدا ہوں گے۔ کم از کم کہنا ایک مثالی منظرنامہ نہیں ہے۔
تھروٹلنگ اور ردعمل کے مسئلے کا اظہار
کنٹینر ٹریکنگ کے لیے کلیدی میٹرک ہے۔ trottling، یہ دکھاتا ہے کہ آپ کے کنٹینر کو کتنی بار گلا گھونٹ دیا گیا ہے۔ ہم نے دلچسپی کے ساتھ کچھ کنٹینرز میں تھروٹلنگ کی موجودگی کو دیکھا، قطع نظر اس سے کہ پروسیسر کا بوجھ انتہائی تھا یا نہیں۔ مثال کے طور پر، آئیے اپنے ایک اہم APIs پر ایک نظر ڈالتے ہیں:
جیسا کہ آپ نیچے دیکھ سکتے ہیں، ہم نے حد مقرر کر دی ہے۔ 800m (0.8 یا 80% کور)، اور بہترین پہنچ پر چوٹی کی اقدار 200m (20% کور)۔ ایسا لگتا ہے کہ سروس کو تھروٹ کرنے سے پہلے ہمارے پاس پروسیسر کی کافی طاقت ہے، تاہم...
آپ نے دیکھا ہو گا کہ پروسیسر کا بوجھ متعین حد سے کم ہونے پر بھی - نمایاں طور پر نیچے - تھروٹلنگ اب بھی ہوتی ہے۔
اس کا سامنا کرتے ہوئے، ہم نے جلد ہی کئی وسائل دریافت کیے (, , ) تھروٹلنگ کی وجہ سے خدمات کی کارکردگی اور رسپانس ٹائم میں کمی کے بارے میں۔
ہم کم CPU بوجھ پر تھروٹلنگ کیوں دیکھتے ہیں؟ مختصر ورژن یہ ہے: "لینکس کرنل میں ایک بگ ہے جو مخصوص پروسیسر کی حدود کے ساتھ کنٹینرز کی غیر ضروری تھروٹلنگ کا سبب بنتا ہے۔" اگر آپ مسئلے کی نوعیت میں دلچسپی رکھتے ہیں، تو آپ پریزنٹیشن پڑھ سکتے ہیں ( и اختیارات) بذریعہ ڈیو چلوک۔
CPU پابندیوں کو ہٹانا (انتہائی احتیاط کے ساتھ)
طویل بحث کے بعد، ہم نے تمام خدمات سے پروسیسر کی پابندیاں ہٹانے کا فیصلہ کیا جو ہمارے صارفین کے لیے براہ راست یا بالواسطہ طور پر اہم فعالیت کو متاثر کرتی ہیں۔
فیصلہ آسان نہیں تھا کیونکہ ہم اپنے کلسٹر کے استحکام کو بہت اہمیت دیتے ہیں۔ ماضی میں، ہم پہلے ہی اپنے کلسٹر کی عدم استحکام کے ساتھ تجربہ کر چکے ہیں، اور پھر خدمات نے بہت زیادہ وسائل استعمال کیے اور اپنے پورے نوڈ کے کام کو سست کر دیا۔ اب سب کچھ کچھ مختلف تھا: ہمیں اس بات کی واضح سمجھ تھی کہ ہم اپنے کلسٹرز سے کیا توقع رکھتے ہیں، اور ساتھ ہی منصوبہ بند تبدیلیوں کو نافذ کرنے کے لیے ایک اچھی حکمت عملی بھی۔
ایک اہم مسئلہ پر کاروباری خط و کتابت۔
جب پابندیاں ہٹا دی جائیں تو اپنے نوڈس کی حفاظت کیسے کریں؟
"غیر محدود" خدمات کی تنہائی:
ماضی میں، ہم نے پہلے ہی کچھ نوڈس کو حالت میں آتے دیکھا ہے۔ notReady, بنیادی طور پر بہت زیادہ وسائل استعمال کرنے والی خدمات کی وجہ سے۔
ہم نے ایسی خدمات کو علیحدہ ("لیبل لگا ہوا") نوڈس میں رکھنے کا فیصلہ کیا تاکہ وہ "متعلقہ" خدمات میں مداخلت نہ کریں۔ نتیجے کے طور پر، کچھ نوڈس کو نشان زد کرکے اور "غیر متعلقہ" خدمات میں رواداری کے پیرامیٹر کو شامل کرکے، ہم نے کلسٹر پر زیادہ کنٹرول حاصل کیا، اور ہمارے لیے نوڈس کے ساتھ مسائل کی نشاندہی کرنا آسان ہوگیا۔ اسی طرح کے عمل کو خود انجام دینے کے لئے، آپ اپنے آپ کو واقف کر سکتے ہیں .
صحیح پروسیسر اور میموری کی درخواست تفویض کرنا:
ہمارا سب سے بڑا خوف یہ تھا کہ یہ عمل بہت زیادہ وسائل استعمال کرے گا اور نوڈ درخواستوں کا جواب دینا بند کر دے گا۔ اب سے (ڈیٹا ڈاگ کی بدولت) ہم اپنے کلسٹر پر تمام سروسز کو واضح طور پر مانیٹر کر سکتے ہیں، میں نے ان کے آپریشن کے کئی مہینوں کا تجزیہ کیا جنہیں ہم نے "غیر متعلقہ" کے طور پر نامزد کرنے کا منصوبہ بنایا تھا۔ میں صرف 20% کے مارجن کے ساتھ زیادہ سے زیادہ CPU استعمال سیٹ کرتا ہوں، اور اس طرح k8s کی جانب سے نوڈ کو دوسری خدمات تفویض کرنے کی کوشش کرنے کی صورت میں نوڈ میں جگہ مختص کی جاتی ہے۔
جیسا کہ آپ گراف میں دیکھ سکتے ہیں، پروسیسر پر زیادہ سے زیادہ بوجھ پہنچ گیا ہے۔ 242m سی پی یو کور (0.242 پروسیسر کور)۔ پروسیسر کی درخواست کے لیے، اس قدر سے تھوڑا بڑا نمبر لینا کافی ہے۔ براہ کرم نوٹ کریں کہ چونکہ خدمات صارف پر مرکوز ہیں، اس لیے چوٹی کے بوجھ کی قدریں ٹریفک کے ساتھ ملتی ہیں۔
میموری کے استعمال اور سوالات کے ساتھ بھی ایسا ہی کریں، اور voila - آپ سب سیٹ اپ ہیں! زیادہ سیکورٹی کے لیے، آپ افقی پوڈ آٹو اسکیلنگ شامل کر سکتے ہیں۔ اس طرح، جب بھی وسائل کا بوجھ زیادہ ہوتا ہے، آٹو اسکیلنگ نئے پوڈز بنائے گی، اور کبرنیٹس انہیں خالی جگہ کے ساتھ نوڈس میں تقسیم کریں گے۔ اگر کلسٹر میں ہی کوئی جگہ باقی نہیں ہے تو، آپ خود کو الرٹ سیٹ کر سکتے ہیں یا ان کی آٹو سکیلنگ کے ذریعے نئے نوڈس کے اضافے کو ترتیب دے سکتے ہیں۔
مائنس میں سے، یہ بات قابل غور ہے کہ ہم ""، یعنی ایک نوڈ پر چلنے والے کنٹینرز کی تعداد۔ ہمارے پاس ٹریفک کی کم کثافت پر بہت زیادہ "آرام" بھی ہو سکتے ہیں، اور یہ بھی امکان ہے کہ آپ پروسیسر کے زیادہ بوجھ تک پہنچ جائیں گے، لیکن آٹو اسکیلنگ نوڈس کو بعد میں مدد کرنی چاہیے۔
نتائج
مجھے گزشتہ چند ہفتوں کے تجربات سے یہ شاندار نتائج شائع کرتے ہوئے خوشی ہو رہی ہے؛ ہم نے پہلے ہی تمام ترمیم شدہ خدمات کے جواب میں نمایاں بہتری دیکھی ہے:
ہم نے اپنے ہوم پیج پر بہترین نتائج حاصل کیے ()، وہاں سروس میں تیزی آئی بائیس بار!
کیا لینکس کرنل بگ فکس ہو گیا ہے؟
جی ہاں، ڈسٹری بیوشن ورژن 4.19 اور اس سے زیادہ۔
تاہم، پڑھنے پر ستمبر 2020 کے دوسرے کے لیے ہم اب بھی اسی طرح کے بگ والے کچھ لینکس پروجیکٹس کا ذکر کرتے ہیں۔ مجھے یقین ہے کہ کچھ لینکس ڈسٹری بیوشنز میں اب بھی یہ بگ موجود ہے اور وہ اسے ٹھیک کرنے پر کام کر رہے ہیں۔
اگر آپ کا ڈسٹری بیوشن ورژن 4.19 سے کم ہے، تو میں تازہ ترین اپ ڈیٹ کرنے کی تجویز کروں گا، لیکن کسی بھی صورت میں آپ کو پروسیسر کی پابندیوں کو ہٹانے کی کوشش کرنی چاہیے اور دیکھنا چاہیے کہ آیا تھروٹلنگ برقرار ہے۔ ذیل میں آپ کوبرنیٹس مینجمنٹ سروسز اور لینکس کی تقسیم کی جزوی فہرست دیکھ سکتے ہیں:
- ڈیبین: تقسیم کے تازہ ترین ورژن میں ضم شدہ فکس، ، اور کافی تازہ لگ رہا ہے ()۔ کچھ پچھلے ورژن بھی ٹھیک ہو سکتے ہیں۔
- Ubuntu: تازہ ترین ورژن میں ضم شدہ فکس
- EKS کو ابھی تک ٹھیک کیا گیا ہے۔ . اگر آپ کا ورژن اس سے کم ہے تو آپ کو AMI کو اپ ڈیٹ کرنا چاہیے۔
- کوپس: у
kops 1.18+مرکزی میزبان تصویر Ubuntu 20.04 ہو گی۔ اگر آپ کا کوپس کا ورژن پرانا ہے، تو آپ کو ٹھیک ہونے کا انتظار کرنا پڑ سکتا ہے۔ اب ہم خود انتظار کر رہے ہیں۔ - GKE (گوگل کلاؤڈ): فکس انٹیگریٹڈ تاہم، تھروٹلنگ کے ساتھ مسائل ہیں .
اگر فکس نے تھروٹلنگ کا مسئلہ حل کر دیا تو کیا کریں؟
مجھے یقین نہیں ہے کہ مسئلہ مکمل طور پر حل ہو گیا ہے۔ جب ہم فکس کے ساتھ کرنل ورژن پر پہنچیں گے تو میں کلسٹر کی جانچ کروں گا اور پوسٹ کو اپ ڈیٹ کروں گا۔ اگر کسی نے پہلے ہی اپ ڈیٹ کیا ہے، تو میں آپ کے نتائج کو پڑھنے میں دلچسپی کروں گا۔
حاصل يہ ہوا
- اگر آپ لینکس کے تحت ڈوکر کنٹینرز کے ساتھ کام کرتے ہیں (کوبرنیٹس، میسوس، سوارم یا دیگر کوئی بات نہیں)، تو آپ کے کنٹینرز تھروٹلنگ کی وجہ سے کارکردگی کھو سکتے ہیں۔
- اپنی تقسیم کے تازہ ترین ورژن میں اس امید پر اپ ڈیٹ کرنے کی کوشش کریں کہ بگ پہلے ہی ٹھیک ہو چکا ہے۔
- پروسیسر کی حدود کو ہٹانے سے مسئلہ حل ہو جائے گا، لیکن یہ ایک خطرناک تکنیک ہے جسے انتہائی احتیاط کے ساتھ استعمال کیا جانا چاہیے (بہتر ہے کہ پہلے دانا کو اپ ڈیٹ کریں اور نتائج کا موازنہ کریں)؛
- اگر آپ نے CPU کی حدود کو ہٹا دیا ہے، تو احتیاط سے اپنے CPU اور میموری کے استعمال کی نگرانی کریں اور یقینی بنائیں کہ آپ کے CPU کے وسائل آپ کی کھپت سے زیادہ ہیں۔
- ایک محفوظ آپشن یہ ہوگا کہ زیادہ ہارڈ ویئر لوڈ ہونے کی صورت میں نئی پوڈز بنانے کے لیے پوڈز کو آٹو اسکیل کیا جائے، تاکہ کبرنیٹس انہیں مفت نوڈس کے لیے تفویض کرے۔
مجھے امید ہے کہ یہ پوسٹ آپ کے کنٹینر سسٹم کی کارکردگی کو بہتر بنانے میں مدد کرے گی۔
PS مصنف قارئین اور مبصرین (انگریزی میں) سے میل کھاتا ہے۔
ماخذ: www.habr.com