ہر Kubernetes وسائل کے لیے، آپ دو قسم کی ضروریات کو ترتیب دے سکتے ہیں - درخواستیں اور حدود۔ پہلا کنٹینر یا پوڈ چلانے کے لیے ضروری مفت نوڈ وسائل کی دستیابی کے لیے کم از کم تقاضوں کو بیان کرتا ہے، دوسرا کنٹینر کے لیے دستیاب وسائل کو سختی سے محدود کرتا ہے۔
جب Kubernetes pods کو شیڈول کرتا ہے، تو یہ بہت ضروری ہے کہ کنٹینرز کے پاس مناسب طریقے سے کام کرنے کے لیے کافی وسائل ہوں۔ اگر آپ وسائل سے محدود نوڈ پر ایک بڑی ایپلیکیشن تعینات کرنے کا منصوبہ بنا رہے ہیں، تو یہ ممکن ہے کہ یہ نہ چلے کیونکہ نوڈ کی میموری کم ہو رہی ہے یا CPU پاور ختم ہو رہی ہے۔ اس مضمون میں، ہم دیکھیں گے کہ آپ وسائل کی درخواستوں اور حدود کا استعمال کرتے ہوئے کمپیوٹنگ پاور کی کمی کو کیسے حل کر سکتے ہیں۔
درخواستیں اور حدود وہ طریقہ کار ہیں جنہیں Kubernetes CPU اور میموری جیسے وسائل کو منظم کرنے کے لیے استعمال کرتا ہے۔ درخواستیں وہ ہیں جو اس بات کو یقینی بناتی ہیں کہ کنٹینر کو مطلوبہ وسیلہ ملے۔ اگر کوئی کنٹینر کسی وسائل کی درخواست کرتا ہے، تو Kubernetes اسے صرف اس نوڈ پر شیڈول کرے گا جو اسے فراہم کر سکتا ہے۔ اس بات کو کنٹرول کرتا ہے کہ کنٹینر کے ذریعہ درخواست کردہ وسائل کبھی بھی ایک خاص قدر سے زیادہ نہیں ہوں گے۔
ایک کنٹینر اپنی کمپیوٹنگ پاور کو صرف ایک خاص حد تک بڑھا سکتا ہے، جس کے بعد یہ محدود ہو جائے گا۔ آئیے دیکھتے ہیں کہ یہ کیسے کام کرتا ہے۔ لہذا، دو قسم کے وسائل ہیں - پروسیسر اور میموری. Kubernetes شیڈولر ان وسائل کے بارے میں ڈیٹا استعمال کرتا ہے تاکہ یہ معلوم کیا جا سکے کہ آپ کے پوڈز کو کہاں چلانا ہے۔ پوڈ کے لیے ایک عام وسائل کی تصریح اس طرح دکھائی دیتی ہے۔
پوڈ میں ہر کنٹینر اپنے سوالات اور حدود متعین کرسکتا ہے، یہ سب اضافی ہے۔ پروسیسر کے وسائل ملیکورس میں بیان کیے گئے ہیں۔ اگر آپ کے کنٹینر کو چلانے کے لیے دو مکمل کور کی ضرورت ہے، تو آپ قیمت کو 2000m پر سیٹ کرتے ہیں۔ اگر کنٹینر کو صرف 1/4 کور کی طاقت کی ضرورت ہے، تو قیمت 250m ہوگی۔ ذہن میں رکھیں کہ اگر آپ سب سے بڑے نوڈ کے کور کی تعداد سے زیادہ CPU وسائل کی قدر تفویض کرتے ہیں، تو آپ کا پوڈ بالکل شروع ہونے کے لیے شیڈول نہیں ہوگا۔ ایسی ہی صورت حال اس صورت میں پیش آئے گی اگر آپ کے پاس ایک Pod ہے جسے چار کور کی ضرورت ہے، اور Kubernetes کلسٹر صرف دو اہم ورچوئل مشینوں پر مشتمل ہے۔
جب تک کہ آپ کی ایپلیکیشن کو خاص طور پر ایک سے زیادہ کور (پیچیدہ سائنسی کمپیوٹنگ اور ڈیٹا بیس آپریشنز جیسے پروگرام ذہن میں آتے ہیں) سے فائدہ اٹھانے کے لیے ڈیزائن نہیں کیا گیا ہے، تب تک بہترین طریقہ یہ ہے کہ CPU کی درخواستوں کو 1 یا اس سے کم پر سیٹ کریں اور پھر اسکیل ایبلٹی کے لیے مزید نقلیں چلائیں۔ یہ حل نظام کو زیادہ لچک اور قابل اعتماد فراہم کرے گا۔
جب بات CPU کی حدود کی ہو تو چیزیں زیادہ دلچسپ ہوجاتی ہیں کیونکہ اسے ایک کمپریس ایبل وسیلہ سمجھا جاتا ہے۔ اگر آپ کی درخواست پروسیسر کی طاقت کی حد تک پہنچنا شروع کر دیتی ہے، تو Kubernetes CPU تھروٹلنگ کا استعمال کرتے ہوئے آپ کے کنٹینر کو سست کرنا شروع کر دے گا - پروسیسر کی فریکوئنسی کو کم کر کے۔ اس کا مطلب ہے کہ CPU کو مصنوعی طور پر تھروٹل کیا جائے گا، جس سے ایپلیکیشن کو ممکنہ طور پر بدتر کارکردگی ملے گی، لیکن اس عمل کو ختم یا ختم نہیں کیا جائے گا۔
میموری وسائل کی وضاحت بائٹس میں کی گئی ہے۔ عام طور پر سیٹنگز میں ویلیو میبی بائٹس Mib میں ماپا جاتا ہے، لیکن آپ بائٹس سے لے کر پیٹا بائٹس تک کوئی بھی ویلیو سیٹ کر سکتے ہیں۔ سی پی یو کی طرح یہاں بھی وہی صورتحال لاگو ہوتی ہے - اگر آپ اپنے نوڈس پر میموری کی مقدار سے زیادہ میموری کی درخواست کرتے ہیں، تو اس پوڈ کو عمل میں لانے کے لیے شیڈول نہیں کیا جائے گا۔ لیکن CPU وسائل کے برعکس، میموری کو کمپریس نہیں کیا جاتا ہے کیونکہ اس کے استعمال کو محدود کرنے کا کوئی طریقہ نہیں ہے۔ اس لیے جیسے ہی کنٹینر اس کے لیے مختص کردہ میموری سے آگے بڑھے گا اس پر عمل درآمد روک دیا جائے گا۔
یہ یاد رکھنا ضروری ہے کہ آپ ان درخواستوں کو ترتیب نہیں دے سکتے جو آپ کے نوڈس کے فراہم کردہ وسائل سے زیادہ ہوں۔ GKE ورچوئل مشینوں کے لیے مشترکہ وسائل کی تفصیلات اس ویڈیو کے نیچے دیے گئے لنکس میں مل سکتی ہیں۔
ایک مثالی دنیا میں، کنٹینر کی ڈیفالٹ ترتیبات کام کے بہاؤ کو آسانی سے چلانے کے لیے کافی ہوں گی۔ لیکن حقیقی دنیا ایسی نہیں ہے، لوگ وسائل کے استعمال کو ترتیب دینا آسانی سے بھول سکتے ہیں، یا ہیکرز ایسی درخواستیں اور پابندیاں لگا دیں گے جو بنیادی ڈھانچے کی حقیقی صلاحیتوں سے زیادہ ہوں۔ اس طرح کے منظرناموں کو ہونے سے روکنے کے لیے، آپ ResourceQuota اور LimitRange ریسورس کوٹہ کنفیگر کر سکتے ہیں۔
ایک بار نام کی جگہ بن جانے کے بعد، اسے کوٹہ کا استعمال کرتے ہوئے بلاک کیا جا سکتا ہے۔ مثال کے طور پر، اگر آپ کے پاس prod اور dev نام کی جگہیں ہیں، تو پیٹرن یہ ہے کہ کوئی پروڈکشن کوٹہ بالکل نہیں ہے اور بہت سخت ترقیاتی کوٹے ہیں۔ یہ ٹریفک میں تیزی سے اضافے کی صورت میں پروڈ کو مکمل طور پر dev کو مسدود کرتے ہوئے، تمام دستیاب وسائل پر قبضہ کرنے کی اجازت دیتا ہے۔
وسائل کا کوٹہ اس طرح نظر آ سکتا ہے۔ اس مثال میں 4 حصے ہیں - یہ کوڈ کی 4 نیچے لائنیں ہیں۔
آئیے ان میں سے ہر ایک کو دیکھتے ہیں۔ Requests.cpu مشترکہ CPU درخواستوں کی زیادہ سے زیادہ تعداد ہے جو نام کی جگہ میں موجود تمام کنٹینرز سے آ سکتی ہیں۔ اس مثال میں، آپ کے پاس 50m درخواستوں کے ساتھ 10 کنٹینرز، 100m درخواستوں کے ساتھ پانچ کنٹینرز، یا 500m درخواستوں کے ساتھ صرف ایک کنٹینر ہو سکتا ہے۔ جب تک کسی دیے گئے نام کی جگہ کی درخواستوں کی کل تعداد 500m سے کم ہے، سب کچھ ٹھیک ہو جائے گا۔
میموری کی درخواست کی گئی درخواستیں.میموری مشترکہ میموری کی درخواستوں کی زیادہ سے زیادہ مقدار ہے جو نام کی جگہ کے تمام کنٹینرز کے پاس ہو سکتی ہے۔ جیسا کہ پچھلے کیس میں، آپ کے پاس 50 2 mib کنٹینرز، پانچ 20 mib کنٹینرز، یا ایک واحد 100 mib کنٹینر ہو سکتا ہے جب تک کہ نام کی جگہ میں درخواست کردہ میموری کی کل مقدار 100 میبی بائٹس سے کم ہو۔
Limits.cpu CPU پاور کی زیادہ سے زیادہ مشترکہ مقدار ہے جسے نام کی جگہ کے تمام کنٹینرز استعمال کر سکتے ہیں۔ ہم اسے پروسیسر پاور کی درخواستوں کی حد سمجھ سکتے ہیں۔
آخر میں، limits.memory مشترکہ میموری کی زیادہ سے زیادہ مقدار ہے جسے نام کی جگہ کے تمام کنٹینرز استعمال کر سکتے ہیں۔ یہ کل میموری کی درخواستوں پر ایک حد ہے۔
لہذا، بطور ڈیفالٹ، Kubernetes کلسٹر میں کنٹینرز لامحدود کمپیوٹ وسائل کے ساتھ چلتے ہیں۔ وسائل کے کوٹے کے ساتھ، کلسٹر منتظمین نام کی جگہ کی بنیاد پر وسائل کی کھپت اور وسائل کی تخلیق کو محدود کر سکتے ہیں۔ نام کی جگہ میں، ایک پوڈ یا کنٹینر زیادہ سے زیادہ CPU پاور اور میموری استعمال کر سکتا ہے جیسا کہ نام کی جگہ کے وسائل کے کوٹہ سے طے ہوتا ہے۔ تاہم، یہ تشویش ہے کہ ایک پوڈ یا کنٹینر تمام دستیاب وسائل پر اجارہ داری کر سکتا ہے۔ اس صورت حال کو روکنے کے لیے، ایک حد کی حد استعمال کی جاتی ہے - نام کی جگہ میں وسائل کی تقسیم کو محدود کرنے کی پالیسی (پڈ یا کنٹینرز کے لیے)۔
حد کی حد ایسی پابندیاں فراہم کرتی ہے جو یہ کر سکتی ہیں:
- نام کی جگہ میں ہر ماڈیول یا کنٹینر کے لیے کمپیوٹنگ وسائل کے کم سے کم اور زیادہ سے زیادہ استعمال کو یقینی بنائیں؛
- نام کی جگہ میں ہر PersistentVolumeClaim کے لیے کم سے کم اور زیادہ سے زیادہ Starage Request سٹوریج کی درخواستوں کو نافذ کریں؛
- نام کی جگہ میں وسائل کے لیے درخواست اور حد کے درمیان تعلق کو نافذ کرنا؛
- نام کی جگہ میں کمپیوٹ وسائل کے لیے پہلے سے طے شدہ درخواستیں/حدیں مقرر کریں اور رن ٹائم کے وقت انہیں خود بخود کنٹینرز میں انجیکشن کریں۔
اس طرح آپ اپنے نام کی جگہ میں حد کی حد بنا سکتے ہیں۔ کوٹہ کے برعکس، جو کہ پوری نام کی جگہ پر لاگو ہوتا ہے، حد کی حد انفرادی کنٹینرز کے لیے استعمال ہوتی ہے۔ یہ صارفین کو نام کی جگہ کے اندر بہت چھوٹے یا اس کے برعکس بہت بڑے کنٹینرز بنانے سے روک سکتا ہے۔ حد کی حد اس طرح نظر آسکتی ہے۔
پچھلے کیس کی طرح، یہاں 4 حصوں میں فرق کیا جا سکتا ہے۔ آئیے ہر ایک کو دیکھتے ہیں۔
ڈیفالٹ سیکشن پوڈ میں کنٹینر کے لیے پہلے سے طے شدہ حدود کا تعین کرتا ہے۔ اگر آپ ان قدروں کو انتہائی حد میں سیٹ کرتے ہیں، تو کوئی بھی کنٹینر جس کے لیے یہ قدریں واضح طور پر سیٹ نہیں کی گئی ہیں، پہلے سے طے شدہ اقدار کی پیروی کریں گے۔
ڈیفالٹ درخواست سیکشن defaultRequest پوڈ میں کنٹینر کے لیے پہلے سے طے شدہ درخواستوں کو ترتیب دیتا ہے۔ ایک بار پھر، اگر آپ ان اقدار کو انتہائی حد پر سیٹ کرتے ہیں، تو کوئی بھی کنٹینرز جو واضح طور پر ان اختیارات کو سیٹ نہیں کرتے ہیں وہ ان اقدار کے لیے ڈیفالٹ ہو جائیں گے۔
زیادہ سے زیادہ سیکشن زیادہ سے زیادہ حدوں کی وضاحت کرتا ہے جو پوڈ میں کنٹینر کے لیے سیٹ کی جا سکتی ہیں۔ ڈیفالٹ سیکشن میں اقدار اور کنٹینر کی حدیں اس حد سے زیادہ سیٹ نہیں کی جا سکتیں۔ یہ نوٹ کرنا ضروری ہے کہ اگر قدر زیادہ سے زیادہ پر سیٹ ہے اور کوئی ڈیفالٹ سیکشن نہیں ہے، تو زیادہ سے زیادہ قدر ڈیفالٹ قدر بن جاتی ہے۔
کم سے کم سیکشن کم از کم درخواستوں کی وضاحت کرتا ہے جو پوڈ میں کنٹینر کے لیے سیٹ کی جا سکتی ہیں۔ تاہم، ڈیفالٹ سیکشن میں اقدار اور کنٹینر کے لیے سوالات اس حد سے نیچے سیٹ نہیں کیے جا سکتے۔
ایک بار پھر، یہ نوٹ کرنا ضروری ہے کہ اگر یہ ویلیو سیٹ ہے، ڈیفالٹ نہیں ہے، تو کم از کم قدر ڈیفالٹ پرامپٹ بن جاتی ہے۔
یہ وسائل کی درخواستیں بالآخر Kubernetes شیڈیولر آپ کے کام کے بوجھ کو انجام دینے کے لیے استعمال کرتی ہیں۔ اپنے کنٹینرز کو صحیح طریقے سے ترتیب دینے کے لیے، یہ سمجھنا بہت ضروری ہے کہ یہ کیسے کام کرتا ہے۔ فرض کریں کہ آپ اپنے کلسٹر میں ایک سے زیادہ پوڈ چلانا چاہتے ہیں۔ یہ فرض کرتے ہوئے کہ پوڈ کی وضاحتیں درست ہیں، Kubernetes شیڈول کام کے بوجھ کو چلانے کے لیے ایک نوڈ کو منتخب کرنے کے لیے راؤنڈ رابن بیلنسنگ کا استعمال کرے گا۔
Kubernetes چیک کرے گا کہ آیا نوڈ 1 کے پاس پوڈ کنٹینرز کی درخواستوں کو پورا کرنے کے لیے کافی وسائل ہیں، اور اگر ایسا نہیں ہوتا ہے، تو یہ اگلے نوڈ پر چلا جائے گا۔ اگر سسٹم میں موجود نوڈس میں سے کوئی بھی درخواستوں کو پورا کرنے کے قابل نہیں ہے، تو پوڈز زیر التواء حالت میں چلے جائیں گے۔ Google Kubernetes انجن کی خصوصیات جیسے کہ نوڈ آٹو اسکیلنگ کا استعمال کرتے ہوئے، GKE خود بخود انتظار کی حالت کا پتہ لگا سکتا ہے اور کئی اضافی نوڈس بنا سکتا ہے۔
اگر بعد میں آپ کے نوڈ کی گنجائش ختم ہو جاتی ہے، تو آٹو سکیلنگ آپ کے پیسے بچانے کے لیے نوڈس کی تعداد کو کم کر دے گی۔ یہی وجہ ہے کہ Kubernetes درخواستوں کی بنیاد پر پوڈ کو شیڈول کرتا ہے۔ تاہم، حد درخواستوں سے زیادہ ہو سکتی ہے، اور بعض صورتوں میں نوڈ میں اصل میں وسائل ختم ہو سکتے ہیں۔ ہم اس ریاست کو اوور کمٹمنٹ سٹیٹ کہتے ہیں۔
جیسا کہ میں نے کہا، جب بات CPU کی ہو تو، Kubernetes پھلیوں کو محدود کرنا شروع کر دے گا۔ ہر پوڈ کو اتنا ہی ملے گا جتنا اس نے درخواست کی ہے، لیکن اگر یہ حد تک نہیں پہنچتی ہے، تو تھروٹلنگ لاگو ہونا شروع ہو جائے گی۔
جب میموری کے وسائل کی بات آتی ہے تو، Kubernetes کو یہ فیصلہ کرنے پر مجبور کیا جاتا ہے کہ کون سے پوڈز کو حذف کرنا ہے اور کن کو اس وقت تک رکھنا ہے جب تک کہ آپ سسٹم کے وسائل کو خالی نہیں کر دیتے یا پورا سسٹم کریش نہیں ہو جاتا۔
آئیے ایک ایسے منظر نامے کا تصور کریں جہاں آپ کی میموری ختم ہو رہی ہو - کبرنیٹس اسے کیسے سنبھالیں گے؟
Kubernetes ایسے پوڈز کو تلاش کریں گے جو ان کی درخواست سے زیادہ وسائل استعمال کر رہے ہیں۔ لہذا اگر آپ کے کنٹینرز میں کوئی درخواست نہیں ہے، تو اس کا مطلب ہے کہ وہ اپنے مانگے سے زیادہ استعمال کرنے میں ڈیفالٹ کر رہے ہیں، صرف اس وجہ سے کہ انہوں نے کچھ بھی نہیں مانگا! ایسے کنٹینرز شٹ ڈاؤن کے اہم امیدوار بن جاتے ہیں۔ اگلے امیدوار وہ کنٹینرز ہیں جنہوں نے اپنی تمام درخواستیں پوری کر لی ہیں لیکن پھر بھی زیادہ سے زیادہ حد سے نیچے ہیں۔
لہذا اگر Kubernetes کو متعدد پوڈز ملتے ہیں جو ان کی درخواست کے پیرامیٹرز سے تجاوز کر چکے ہیں، تو یہ انہیں ترجیح کے مطابق ترتیب دے گا اور پھر سب سے کم ترجیحی پوڈز کو ہٹا دے گا۔ اگر تمام پوڈز کی ترجیح ایک جیسی ہے، تو Kubernetes ان پوڈز کو ختم کر دے گا جو ان کی درخواستوں سے دوسرے پوڈز سے زیادہ ہیں۔
بہت ہی غیر معمولی معاملات میں، Kubernetes ایسے پوڈز کو روک سکتے ہیں جو ابھی تک ان کی درخواستوں کے دائرہ کار میں ہیں۔ یہ اس وقت ہو سکتا ہے جب نظام کے اہم اجزاء جیسے کیوبلیٹ ایجنٹ یا ڈوکر ان کے لیے مختص کردہ وسائل سے زیادہ وسائل استعمال کرنا شروع کر دیں۔
لہذا، چھوٹی کمپنیوں کے ابتدائی مراحل میں، ایک Kubernetes کلسٹر وسائل کی درخواستوں اور پابندیوں کو ترتیب دیے بغیر ٹھیک کام کر سکتا ہے، لیکن جیسے جیسے آپ کی ٹیمیں اور پروجیکٹ سائز میں بڑھنے لگتے ہیں، آپ اس علاقے میں مسائل کا شکار ہونے کا خطرہ چلاتے ہیں۔ آپ کے ماڈیولز اور نام کی جگہوں میں سوالات اور رکاوٹوں کو شامل کرنے کے لیے بہت کم اضافی کوشش کی ضرورت ہوتی ہے اور یہ بہت زیادہ پریشانی کو بچا سکتا ہے۔
کچھ اشتہارات 🙂
ہمارے ساتھ رہنے کے لیے آپ کا شکریہ۔ کیا آپ کو ہمارے مضامین پسند ہیں؟ مزید دلچسپ مواد دیکھنا چاہتے ہیں؟ آرڈر دے کر یا دوستوں کو مشورہ دے کر ہمارا ساتھ دیں، , انٹری لیول سرورز کا ایک انوکھا اینالاگ، جو ہم نے آپ کے لیے ایجاد کیا تھا: (RAID1 اور RAID10 کے ساتھ دستیاب، 24 کور تک اور 40GB DDR4 تک)۔
ایمسٹرڈیم میں Equinix Tier IV ڈیٹا سینٹر میں Dell R730xd 2 گنا سستا؟ صرف یہاں نیدرلینڈ میں! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 سے! کے بارے میں پڑھا
ماخذ: www.habr.com