کبرنیٹس کلسٹر بناتے وقت، سوالات پیدا ہوسکتے ہیں: کتنے ورکر نوڈس کو کنفیگر کرنا ہے اور کس قسم کا؟ آن پریمیس کلسٹر کے لیے کیا بہتر ہے: کئی طاقتور سرور خریدیں یا اپنے ڈیٹا سینٹر میں درجن بھر پرانی مشینیں استعمال کریں؟ کیا کلاؤڈ میں آٹھ سنگل کور یا دو کواڈ کور مثالیں لینا بہتر ہے؟
ان سوالات کے جوابات مضمون میں موجود ہیں۔ کمانڈ کے ترجمہ میں .
کلسٹر کی گنجائش
عام طور پر، ایک Kubernetes کلسٹر کو ایک بڑے "سپر نوڈ" کے طور پر سوچا جا سکتا ہے۔ اس کی کل کمپیوٹنگ طاقت اس کے تمام اجزاء نوڈس کی طاقتوں کا مجموعہ ہے۔
آپ کے مطلوبہ کلسٹر صلاحیت کے ہدف کو حاصل کرنے کے کئی طریقے ہیں۔ مثال کے طور پر، ہمیں 8 پروسیسر کور اور 32 جی بی ریم کی کل صلاحیت کے ساتھ کلسٹر کی ضرورت ہے کیونکہ ایپلی کیشنز کے ایک سیٹ کے لیے بہت سارے وسائل کی ضرورت ہوتی ہے۔ پھر آپ 16 جی بی میموری والے دو نوڈس یا 8 جی بی میموری والے چار نوڈس، دو کواڈ کور پروسیسرز یا چار ڈوئل کور والے انسٹال کر سکتے ہیں۔
یہاں کلسٹر بنانے کے صرف دو ممکنہ طریقے ہیں:
دونوں اختیارات ایک ہی صلاحیت کے ساتھ ایک کلسٹر تیار کرتے ہیں، لیکن نیچے کی ترتیب میں چار چھوٹے نوڈس ہیں اور اوپر کی ترتیب میں دو بڑے نوڈس ہیں۔
کون سا آپشن بہتر ہے؟
اس سوال کا جواب دینے کے لیے، آئیے دونوں اختیارات کے فوائد کو دیکھتے ہیں۔ ہم نے ان کا خلاصہ ایک جدول میں کیا ہے۔
کئی بڑے نوڈس
بہت سے چھوٹے نوڈس
آسان کلسٹر مینجمنٹ (اگر یہ بنیاد پر ہے)
ہموار آٹو اسکیلنگ
سستا (اگر بنیاد پر ہو)
قیمت تھوڑی مختلف ہے (بادل میں)
وسائل سے بھرپور ایپلی کیشنز چلا سکتے ہیں۔
مکمل نقل
وسائل کو زیادہ مؤثر طریقے سے استعمال کیا جاتا ہے (سسٹم ڈیمن پر کم اوور ہیڈ
اعلی کلسٹر فالٹ رواداری
براہ کرم نوٹ کریں کہ ہم صرف ورکر نوڈس کے بارے میں بات کر رہے ہیں۔ مین نوڈس کی تعداد اور سائز کا انتخاب بالکل مختلف موضوع ہے۔
تو آئیے ٹیبل سے ہر ایک نکتے پر مزید تفصیل سے بات کریں۔
پہلا آپشن: کئی بڑے نوڈس
کلسٹر کی پوری صلاحیت کے لیے سب سے زیادہ آپشن ایک ورکر نوڈ ہے۔ اوپر دی گئی مثال میں، یہ 16 سی پی یو کور اور 16 جی بی ریم کے ساتھ واحد ورکر نوڈ ہوگا۔
پیشہ
پلس نمبر 1۔ آسان انتظام
پورے بیڑے کے مقابلے میں چند مشینوں کا انتظام کرنا آسان ہے۔ اپ ڈیٹس اور اصلاحات کو رول آؤٹ کرنا تیز تر ہے، اور ہم وقت سازی کرنا آسان ہے۔ مطلق نمبروں میں ناکامیوں کی تعداد بھی کم ہے۔
براہ کرم نوٹ کریں کہ مذکورہ بالا تمام چیزیں آپ کے ہارڈ ویئر، آپ کے سرورز پر لاگو ہوتی ہیں، نہ کہ کلاؤڈ انسٹینس پر۔
بادل میں صورتحال مختلف ہے۔ وہاں، انتظام کلاؤڈ سروس فراہم کرنے والے کے ذریعہ سنبھالا جاتا ہے۔ اس طرح، کلاؤڈ میں دس نوڈس کا انتظام ایک نوڈ کے انتظام سے زیادہ مختلف نہیں ہے۔
بادل میں پوڈز کے درمیان ٹریفک روٹنگ اور لوڈ کی تقسیم : انٹرنیٹ سے آنے والی ٹریفک کو مین لوڈ بیلنسر پر بھیجا جاتا ہے، جو ٹریفک کو نوڈس میں سے ایک کی بندرگاہ پر بھیجتا ہے (نوڈ پورٹ سروس ہر کلسٹر نوڈ میں پورٹ کو 30000-32767 کی حد میں سیٹ کرتی ہے)۔ kube-proxy کے ذریعہ مقرر کردہ قوانین نوڈ سے پوڈ کی طرف ٹریفک کو ری ڈائریکٹ کرتے ہیں۔ دو نوڈس پر دس پوڈز کے لیے یہ کیسا لگتا ہے:
پرو #2: فی نوڈ کم قیمت
ایک طاقتور کار زیادہ مہنگی ہوتی ہے، لیکن قیمت میں اضافہ ضروری نہیں کہ لکیری ہو۔ دوسرے الفاظ میں، 10 GB میموری والا ایک دس کور سرور عام طور پر اتنی ہی میموری والے دس سنگل کور سرورز سے سستا ہوتا ہے۔
لیکن نوٹ کریں کہ یہ اصول عام طور پر کلاؤڈ سروسز میں کام نہیں کرتا ہے۔ تمام بڑے کلاؤڈ فراہم کنندگان کی موجودہ قیمتوں کے تعین کی اسکیموں میں، قیمتیں صلاحیت کے ساتھ لکیری طور پر بڑھتی ہیں۔
اس طرح، بادل میں آپ عام طور پر زیادہ طاقتور سرورز پر محفوظ نہیں کر سکتے ہیں۔
پرو #3: آپ وسائل سے بھرپور ایپلی کیشنز چلا سکتے ہیں۔
کچھ ایپلیکیشنز کو کلسٹر میں طاقتور سرورز کی ضرورت ہوتی ہے۔ مثال کے طور پر، اگر مشین لرننگ سسٹم کو 8 جی بی میموری کی ضرورت ہے، تو آپ اسے 1 جی بی نوڈس پر نہیں چلا سکیں گے، لیکن صرف کم از کم ایک بڑے ورکر نوڈ کے ساتھ۔
Cons
نقصان نمبر 1. فی نوڈ بہت سے پوڈز
اگر یہی کام کم نوڈس پر انجام دیا جاتا ہے، تو قدرتی طور پر ان میں سے ہر ایک کے پاس زیادہ پوڈ ہوں گے۔
یہ ایک مسئلہ ہو سکتا ہے.
وجہ یہ ہے کہ ہر ماڈیول کنٹینر کے رن ٹائم (جیسے ڈوکر) کے ساتھ ساتھ کیوبلیٹ اور سی ایڈوائزر کے لیے کچھ اوور ہیڈ متعارف کراتا ہے۔
مثال کے طور پر، ایک کیوبلیٹ باقاعدگی سے ایک نوڈ پر موجود تمام کنٹینرز کی بقا کے لیے تحقیقات کرتا ہے — جتنے زیادہ کنٹینرز ہوں گے، کیوبلیٹ کو اتنا ہی زیادہ کام کرنا پڑتا ہے۔
CAdvisor ایک نوڈ پر موجود تمام کنٹینرز کے لیے وسائل کے استعمال کے اعداد و شمار جمع کرتا ہے، اور کیوبلیٹ باقاعدگی سے اس معلومات سے استفسار کرتا ہے اور اسے API کے ذریعے فراہم کرتا ہے۔ ایک بار پھر، زیادہ کنٹینرز کا مطلب ہے cAdvisor اور kubelet دونوں کے لیے زیادہ کام۔
اگر ماڈیولز کی تعداد بڑھ جاتی ہے، تو یہ نظام کو سست کر سکتا ہے اور اس کی وشوسنییتا کو بھی نقصان پہنچا سکتا ہے۔
Kubernetes ذخیرہ میں کچھ وہ نوڈس ریڈی/نوٹ ریڈی سٹیٹس کے درمیان چھلانگ لگاتے ہیں کیونکہ نوڈ پر موجود تمام کنٹینرز کی باقاعدہ کبلیٹ چیک میں بہت زیادہ وقت لگتا ہے۔
اس وجہ سے Kubernetes . نوڈ کی کارکردگی پر منحصر ہے، آپ فی نوڈ مزید پوڈ چلا سکتے ہیں، لیکن یہ پیش گوئی کرنا مشکل ہے کہ آیا مسائل ہوں گے یا سب کچھ ٹھیک کام کرے گا۔ یہ پیشگی کام کی جانچ کے قابل ہے.
نقصان نمبر 2. نقل پر حد
بہت کم نوڈس درخواست کی نقل کی مؤثر حد کو محدود کرتے ہیں۔ مثال کے طور پر، اگر آپ کے پاس پانچ ریپلیکاز کے ساتھ اعلی دستیابی کی ایپلی کیشن ہے لیکن صرف دو نوڈس، تو پھر ایپلیکیشن کی نقل کی مؤثر ڈگری کو کم کر کے دو کر دیا جاتا ہے۔
پانچ نقلیں صرف دو نوڈس میں تقسیم کی جا سکتی ہیں، اور اگر ان میں سے کوئی ایک ناکام ہو جاتا ہے، تو یہ ایک ہی وقت میں متعدد نقلیں اتار دیتا ہے۔
اگر آپ کے پاس پانچ نوڈس یا اس سے زیادہ ہیں، تو ہر ایک نقل الگ نوڈ پر چلے گی، اور ایک نوڈ کی ناکامی زیادہ سے زیادہ ایک نقل ہٹا دے گی۔
اس طرح، اعلی دستیابی کی ضروریات کے لیے کلسٹر میں نوڈس کی ایک مخصوص کم از کم تعداد کی ضرورت پڑ سکتی ہے۔
نقصان نمبر 3۔ ناکامی کے بدتر نتائج
نوڈس کی ایک چھوٹی سی تعداد کے ساتھ، ہر ناکامی کے زیادہ سنگین نتائج ہوتے ہیں۔ مثال کے طور پر، اگر آپ کے پاس صرف دو نوڈس ہیں اور ان میں سے ایک ناکام ہو جاتا ہے، تو آپ کے آدھے ماڈیول فوراً غائب ہو جاتے ہیں۔
بلاشبہ، Kubernetes کام کے بوجھ کو ناکام نوڈ سے دوسروں میں منتقل کر دے گا۔ لیکن اگر ان میں سے چند ہیں، تو شاید اتنی مفت گنجائش نہ ہو۔ نتیجے کے طور پر، آپ کی کچھ درخواستیں اس وقت تک دستیاب نہیں ہوں گی جب تک کہ آپ ناکام نوڈ کو سامنے نہیں لاتے۔
اس طرح، جتنے زیادہ نوڈز، ہارڈ ویئر کی ناکامیوں کا اثر اتنا ہی کم ہوگا۔
نقصان #4: آٹو اسکیلنگ کے مزید اقدامات
Kubernetes میں کلاؤڈ انفراسٹرکچر کے لیے کلسٹر آٹو اسکیلنگ سسٹم ہے، جو آپ کو اپنی موجودہ ضروریات کے مطابق نوڈس کو خود بخود شامل کرنے یا ہٹانے کی اجازت دیتا ہے۔ بڑے نوڈس کے ساتھ، آٹو اسکیلنگ زیادہ اچانک اور پیچیدہ ہو جاتی ہے۔ مثال کے طور پر، دو نوڈس پر، ایک اضافی نوڈ شامل کرنے سے فوری طور پر کلسٹر کی صلاحیت میں 50% اضافہ ہو جائے گا۔ اور آپ کو ان وسائل کی ادائیگی کرنی پڑے گی، چاہے آپ کو ان کی ضرورت نہ ہو۔
اس طرح، اگر آپ خودکار کلسٹر اسکیلنگ استعمال کرنے کا ارادہ رکھتے ہیں، نوڈس جتنے چھوٹے ہوں گے، اتنی ہی زیادہ لچکدار اور لاگت سے موثر اسکیلنگ آپ کو ملے گی۔
اب آئیے چھوٹے نوڈس کی ایک بڑی تعداد کے فوائد اور نقصانات کو دیکھتے ہیں۔
دوسرا آپشن: بہت سے چھوٹے نوڈس
اس نقطہ نظر کے فوائد بنیادی طور پر متعدد بڑے نوڈس کے ساتھ مخالف آپشن کے نقصانات سے پیدا ہوتے ہیں۔
پیشہ
پرو # 1: ناکامی کا کم اثر
جتنے زیادہ نوڈس، ہر نوڈ پر کم پوڈز۔ مثال کے طور پر، اگر آپ کے پاس فی دس نوڈس سو ماڈیولز ہیں، تو ہر نوڈ میں اوسطاً دس ماڈیولز ہوں گے۔
اس طرح، اگر نوڈس میں سے کوئی ایک ناکام ہوجاتا ہے، تو آپ صرف 10 فیصد کام کا بوجھ کھو دیتے ہیں۔ امکانات یہ ہیں کہ نقلوں کی صرف ایک چھوٹی سی تعداد متاثر ہوگی اور مجموعی طور پر ایپلی کیشن فعال رہے گی۔
مزید برآں، بقیہ نوڈس کے پاس ناکام نوڈ کے کام کے بوجھ کو سنبھالنے کے لیے کافی مفت وسائل ہونے کا امکان ہے، لہذا Kubernetes آزادانہ طور پر پوڈز کو دوبارہ ترتیب دے سکتا ہے اور آپ کی ایپلی کیشنز نسبتا تیزی سے فعال حالت میں واپس آجائیں گی۔
پرو # 2: اچھی نقل
اگر کافی نوڈس ہیں تو، Kubernetes شیڈیولر تمام نقلوں کو مختلف نوڈس تفویض کر سکتا ہے۔ اس طرح، اگر کوئی نوڈ ناکام ہوجاتا ہے، تو صرف ایک نقل متاثر ہوگی اور درخواست دستیاب رہے گی۔
Cons
نقصان نمبر 1۔ کنٹرول کرنا مشکل
نوڈس کی بڑی تعداد کا انتظام کرنا زیادہ مشکل ہے۔ مثال کے طور پر، ہر Kubernetes نوڈ کو باقی تمام لوگوں کے ساتھ بات چیت کرنی چاہیے، یعنی کنکشن کی تعداد چوکور طور پر بڑھتی ہے، اور ان تمام کنکشنز کو ٹریک کرنے کی ضرورت ہے۔
Kubernetes کنٹرولر مینیجر میں نوڈ کنٹرولر صحت کی جانچ کرنے کے لیے کلسٹر کے تمام نوڈس کے ذریعے باقاعدگی سے چلتا ہے - جتنے زیادہ نوڈز، کنٹرولر پر اتنا ہی زیادہ بوجھ۔
ای سی ڈی ڈیٹا بیس پر بوجھ بھی بڑھ رہا ہے - ہر ایک کبلیٹ اور کیوب پراکسی کالز etcd کے لیے (API کے ذریعے)، جس میں etcd کو آبجیکٹ اپ ڈیٹ نشر کرنا چاہیے۔
عام طور پر، ہر ورکر نوڈ ماسٹر نوڈس کے سسٹم کے اجزاء پر اضافی بوجھ عائد کرتا ہے۔
Kubernetes باضابطہ طور پر کلسٹرز کی حمایت کرتا ہے۔ . تاہم، عملی طور پر پہلے ہی 500 نوڈس موجود ہیں۔ .
کارکن نوڈس کی ایک بڑی تعداد کو منظم کرنے کے لیے، آپ کو زیادہ طاقتور ماسٹر نوڈس کا انتخاب کرنا چاہیے۔ مثال کے طور پر، کیوب اپ ورکر نوڈس کی تعداد کے لحاظ سے ماسٹر نوڈ کے لیے درست VM سائز۔ یعنی، جتنے زیادہ ورکر نوڈس، اتنے ہی زیادہ پیداواری ماسٹر نوڈس ہونے چاہئیں۔
ان مخصوص مسائل کو حل کرنے کے لیے خصوصی پیشرفت ہوتی ہے، جیسے . یہ سسٹم آپ کو پابندیوں کو نظرانداز کرنے اور کارکن نوڈس کی ایک بڑی تعداد کے ساتھ کلسٹر بنانے کی اجازت دیتا ہے۔
نقصان نمبر 2: زیادہ اوور ہیڈ اخراجات۔
ہر ورکر نوڈ پر، Kubernetes سسٹم ڈیمونز کا ایک سیٹ چلاتا ہے - ان میں کنٹینر رن ٹائم (جیسے Docker)، kube-proxy اور kubelet، بشمول cAdvisor۔ وہ ایک ساتھ مل کر ایک مقررہ مقدار میں وسائل استعمال کرتے ہیں۔
اگر آپ کے پاس بہت سے چھوٹے نوڈس ہیں، تو ہر نوڈ پر اس اوور ہیڈ کا تناسب بڑا ہے۔ مثال کے طور پر، تصور کریں کہ ایک ہی نوڈ پر تمام سسٹم ڈیمن ایک ساتھ 0,1 CPU کور اور 0,1 GB میموری استعمال کرتے ہیں۔ اگر آپ کے پاس 10 جی بی میموری کے ساتھ ایک دس کور نوڈ ہے، تو ڈیمن کلسٹر کی گنجائش کا 1٪ استعمال کرتے ہیں۔ دوسری طرف، 1 GB میموری والے دس سنگل کور نوڈس پر، ڈیمن کلسٹر کی گنجائش کا 10% لیں گے۔
اس طرح، کم نوڈس، زیادہ مؤثر طریقے سے بنیادی ڈھانچہ استعمال کیا جاتا ہے.
نقصان نمبر 3۔ وسائل کا غیر موثر استعمال
چھوٹے نوڈس پر، یہ ہو سکتا ہے کہ باقی وسائل کے حصے کسی بھی کام کا بوجھ تفویض کرنے کے لیے بہت چھوٹے ہوں، اس لیے وہ غیر استعمال شدہ رہیں۔
مثال کے طور پر، ہر پوڈ کو 0,75 GB میموری کی ضرورت ہوتی ہے۔ اگر آپ کے پاس دس نوڈس ہیں، ہر ایک 1GB میموری کے ساتھ، آپ دس پوڈز چلا سکتے ہیں، ہر نوڈ کو 0,25GB غیر استعمال شدہ میموری کے ساتھ چھوڑ کر۔
اس کا مطلب ہے کہ کلسٹر کی 25% میموری ضائع ہو جاتی ہے۔
10 جی بی میموری والے بڑے نوڈ پر، آپ ان میں سے 13 ماڈیول چلا سکتے ہیں - اور 0,25 جی بی کا صرف ایک غیر استعمال شدہ ٹکڑا ہوگا۔
اس صورت میں، میموری کا صرف 2,5 فیصد ضائع ہوتا ہے۔
اس طرح، وسائل کو بڑے نوڈس پر زیادہ بہتر طریقے سے استعمال کیا جاتا ہے۔
کئی بڑے نوڈس یا بہت سے چھوٹے؟
تو، کون سا بہتر ہے: ایک کلسٹر میں چند بڑے نوڈس یا بہت سے چھوٹے؟ ہمیشہ کی طرح، کوئی واضح جواب نہیں ہے۔ زیادہ تر درخواست کی قسم پر منحصر ہے۔
مثال کے طور پر، اگر کسی ایپلیکیشن کو 10 GB میموری کی ضرورت ہے، تو بڑے نوڈس ایک واضح انتخاب ہیں۔ اور اگر ایپلی کیشن کو زیادہ دستیابی کے لیے دس گنا نقل کی ضرورت ہے، تو صرف دو نوڈس پر نقلیں لگانے کے خطرے کے قابل نہیں ہے - کلسٹر میں کم از کم دس نوڈس ہونے چاہئیں۔
درمیانی حالات میں، ہر آپشن کے فوائد اور نقصانات کی بنیاد پر انتخاب کریں۔ شاید کچھ دلائل دوسروں کے مقابلے میں آپ کی صورتحال سے زیادہ متعلقہ ہوں۔
اور تمام نوڈس کو ایک ہی سائز کا بنانا بالکل بھی ضروری نہیں ہے۔ کوئی بھی چیز آپ کو پہلے ایک ہی سائز کے نوڈس کے ساتھ تجربہ کرنے، پھر ان میں مختلف سائز کے نوڈس کو شامل کرنے، انہیں ایک کلسٹر میں جوڑنے سے نہیں روکتی ہے۔ Kubernetes کلسٹر میں ورکر نوڈس مکمل طور پر متفاوت ہو سکتے ہیں۔ لہذا آپ دونوں طریقوں کے فوائد کو یکجا کرنے کی کوشش کر سکتے ہیں۔
کوئی واحد نسخہ نہیں ہے، اور ہر صورت حال کی اپنی باریکیاں ہیں، اور صرف پیداوار ہی سچائی دکھائے گی۔
کلاؤڈ پلیٹ فارم ٹیم کے ذریعہ تیار کردہ ترجمہ .
Kubernetes کے بارے میں مزید: .
ماخذ: www.habr.com