نوٹ. ترجمہ: یہ مواد ایک تعلیمی منصوبے سے ہے۔ Kubernetes پر مبنی انفراسٹرکچر کو ڈیزائن کرتے وقت ایک مقبول سوال کا جواب ہے۔ ہم امید کرتے ہیں کہ ہر آپشن کے فوائد اور نقصانات کی کافی تفصیلی وضاحت آپ کو اپنے پروجیکٹ کے لیے بہترین انتخاب کرنے میں مدد کرے گی۔
TL؛ ڈاکٹر: کام کے بوجھ کے ایک ہی سیٹ کو کئی بڑے کلسٹرز پر چلایا جا سکتا ہے (ہر کلسٹر میں کام کے بوجھ کی ایک بڑی تعداد ہوگی) یا بہت سے چھوٹے پر (ہر کلسٹر میں بہت کم بوجھ کے ساتھ)۔
ذیل میں ایک جدول ہے جو ہر نقطہ نظر کے فوائد اور نقصانات کا جائزہ لیتا ہے:
جب Kubernetes کو ایپلیکیشنز چلانے کے لیے پلیٹ فارم کے طور پر استعمال کرتے ہیں، تو کلسٹرز کے قیام کی پیچیدگیوں کے بارے میں اکثر کئی بنیادی سوالات پیدا ہوتے ہیں:
- مجھے کتنے کلسٹر استعمال کرنے چاہئیں؟
- میں انہیں کتنا بڑا بناؤں؟
- ہر کلسٹر میں کیا شامل ہونا چاہئے؟
اس مضمون میں، میں ان تمام سوالوں کا جواب دینے کی کوشش کروں گا جس میں ہر نقطہ نظر کے فوائد اور نقصانات کا تجزیہ کیا جائے گا۔
ایک سوال کا بیان۔
ایک سافٹ ویئر ڈویلپر کے طور پر، آپ ممکنہ طور پر ایک ہی وقت میں بہت سی ایپلیکیشنز تیار اور چلاتے ہیں۔
اس کے علاوہ، ان ایپلی کیشنز کی بہت سی مثالوں کے مختلف ماحول میں چلنے کا امکان ہے - مثال کے طور پر، یہ ہو سکتے ہیں۔ دیو, ٹیسٹ и پرو.
نتیجہ ایپلی کیشنز اور ماحولیات کا ایک مکمل میٹرکس ہے:
ایپلی کیشنز اور ماحولیات
اوپر دی گئی مثال 3 ایپلی کیشنز اور 3 ماحولیات کی نمائندگی کرتی ہے، جس کے نتیجے میں کل 9 ممکنہ اختیارات ہیں۔
ہر درخواست کی مثال ایک خود مختار تعیناتی یونٹ ہے جو دوسروں کے ساتھ آزادانہ طور پر کام کر سکتی ہے۔
براہ کرم نوٹ کریں درخواست کی مثال بہت سے پر مشتمل ہو سکتا ہے اجزاء، جیسے فرنٹ اینڈ، بیک اینڈ، ڈیٹا بیس، وغیرہ۔ مائیکرو سروسز ایپلی کیشن کی صورت میں، مثال میں تمام مائیکرو سروسز شامل ہوں گی۔
نتیجے کے طور پر، Kubernetes صارفین کے کئی سوالات ہیں:
- کیا تمام درخواستی مثالوں کو ایک کلسٹر میں رکھنا چاہئے؟
- کیا ہر درخواست کی مثال کے لیے الگ کلسٹر رکھنے کے قابل ہے؟
- یا شاید مندرجہ بالا طریقوں کا ایک مجموعہ استعمال کیا جانا چاہئے؟
یہ تمام اختیارات کافی قابل عمل ہیں، کیونکہ Kubernetes ایک لچکدار نظام ہے جو صارف کی صلاحیتوں کو محدود نہیں کرتا۔
یہاں کچھ ممکنہ طریقے ہیں:
- ایک بڑا مشترکہ کلسٹر؛
- بہت سے چھوٹے انتہائی خصوصی کلسٹرز؛
- فی درخواست ایک کلسٹر؛
- ایک کلسٹر فی ماحول۔
جیسا کہ ذیل میں دکھایا گیا ہے، پہلے دو نقطہ نظر اختیارات کے پیمانے کے مخالف سروں پر ہیں:
چند بڑے کلسٹرز (بائیں) سے لے کر بہت سے چھوٹے (دائیں) تک
عام طور پر، ایک کلسٹر کو دوسرے سے "بڑا" سمجھا جاتا ہے اگر اس میں نوڈس اور پوڈز کا بڑا مجموعہ ہو۔ مثال کے طور پر، 10 نوڈس اور 100 پوڈز والا کلسٹر 1 نوڈ اور 10 پوڈز والے کلسٹر سے بڑا ہے۔
ٹھیک ہے، چلو شروع کرتے ہیں!
1. ایک بڑا مشترکہ کلسٹر
پہلا آپشن تمام کام کے بوجھ کو ایک کلسٹر میں رکھنا ہے:
ایک بڑا جھرمٹ
اس نقطہ نظر کے اندر، کلسٹر کو یونیورسل کے طور پر استعمال کیا جاتا ہے۔ بنیادی ڈھانچے کا پلیٹ فارم - آپ موجودہ Kubernetes کلسٹر میں اپنی ضرورت کی ہر چیز کو آسانی سے تعینات کرتے ہیں۔
Kubernetes کلسٹر کے حصوں کو منطقی طور پر ایک دوسرے سے الگ کرنے کی اجازت دیتا ہے، تاکہ ہر ایپلیکیشن کی مثال کا اپنا نام کی جگہ ہو۔
آئیے اس نقطہ نظر کے فوائد اور نقصانات کو دیکھیں۔
+ وسائل کا موثر استعمال
ایک کلسٹر کے ساتھ، آپ کو کوبرنیٹس کلسٹر کو چلانے اور اس کا نظم کرنے کے لیے درکار تمام وسائل کی صرف ایک کاپی درکار ہے۔
مثال کے طور پر، یہ ماسٹر نوڈس کے لیے درست ہے۔ عام طور پر، ہر Kubernetes کلسٹر میں 3 ماسٹر نوڈس ہوتے ہیں، لہذا ایک واحد کلسٹر کے لیے ان کی تعداد اسی طرح رہے گی (مقابلے کے لیے، 10 کلسٹروں کو 30 ماسٹر نوڈس کی ضرورت ہوگی)۔
مندرجہ بالا باریکیوں کا اطلاق پورے کلسٹر میں کام کرنے والی دیگر خدمات پر بھی ہوتا ہے، جیسے لوڈ بیلنسرز، انگریس کنٹرولرز، تصدیق، لاگنگ اور نگرانی کے نظام۔
ایک ہی کلسٹر میں، یہ تمام خدمات ایک ساتھ تمام کام کے بوجھ کے لیے استعمال کی جا سکتی ہیں (ان کی کاپیاں بنانے کی ضرورت نہیں ہے، جیسا کہ ایک سے زیادہ کلسٹرز کا معاملہ ہے)۔
+ سستا
مندرجہ بالا کے نتیجے کے طور پر، کم کلسٹرز عام طور پر سستے ہوتے ہیں کیونکہ کوئی اوور ہیڈ اخراجات نہیں ہوتے ہیں۔
یہ خاص طور پر ماسٹر نوڈس کے لیے درست ہے، جس پر کافی رقم خرچ ہو سکتی ہے، قطع نظر اس کے کہ ان کی میزبانی کیسے کی گئی ہو (آن پریمیسس یا کلاؤڈ میں)۔
کچھ منظم Kubernetes خدمات، جیسے یا ، مفت میں کنٹرول پرت فراہم کریں۔ اس صورت میں، لاگت کا مسئلہ کم شدید ہے.
ایسی منظم خدمات بھی ہیں جو ہر Kubernetes کلسٹر کے آپریشن کے لیے ایک مقررہ فیس وصول کرتی ہیں (مثال کے طور پر، ).
+ موثر انتظامیہ
ایک کلسٹر کا انتظام کئی کے انتظام سے زیادہ آسان ہے۔
انتظامیہ میں درج ذیل کام شامل ہو سکتے ہیں۔
- Kubernetes ورژن اپ ڈیٹ؛
- ایک CI/CD پائپ لائن قائم کرنا؛
- CNI پلگ ان انسٹال کرنا؛
- صارف کی توثیق کا نظام قائم کرنا؛
- رسائی کنٹرولر کی تنصیب؛
اور کئی دوسرے…
ایک کلسٹر کی صورت میں، آپ کو یہ سب صرف ایک بار کرنا پڑے گا۔
بہت سے کلسٹرز کے لیے، آپریشنز کو کئی بار دہرانا پڑے گا، جس کے لیے ممکنہ طور پر عمل میں مستقل مزاجی اور مستقل مزاجی کو یقینی بنانے کے لیے عمل اور ٹولز کے کچھ آٹومیشن کی ضرورت ہوگی۔
اور اب نقصانات کے بارے میں چند الفاظ۔
- ناکامی کا واحد نقطہ
انکار کی صورت میں صرف ایک کلسٹر فوری طور پر کام کرنا بند کر دے گا۔ تمام کام کا بوجھ!
چیزیں غلط ہو سکتی ہیں بہت سے طریقے ہیں:
- Kubernetes کو اپ ڈیٹ کرنا غیر متوقع ضمنی اثرات کی طرف جاتا ہے۔
- ایک کلسٹر وسیع جزو (مثال کے طور پر، ایک CNI پلگ ان) توقع کے مطابق کام نہیں کرنا شروع کرتا ہے۔
- کلسٹر اجزاء میں سے ایک صحیح طریقے سے ترتیب نہیں دیا گیا ہے؛
- بنیادی ڈھانچے میں ناکامی.
ایسا ہی ایک واقعہ مشترکہ کلسٹر میں ہوسٹ کیے گئے تمام کام کے بوجھ کو شدید نقصان پہنچا سکتا ہے۔
- کوئی سخت موصلیت نہیں۔
مشترکہ کلسٹر میں چلنے کا مطلب یہ ہے کہ ایپلیکیشنز کلسٹر نوڈس پر ہارڈ ویئر، نیٹ ورکنگ کی صلاحیتوں اور آپریٹنگ سسٹم کو شیئر کرتی ہیں۔
ایک لحاظ سے، ایک ہی نوڈ پر چلنے والے دو مختلف ایپلی کیشنز کے ساتھ دو کنٹینرز ایک ہی مشین پر ایک ہی OS کرنل پر چلنے والے دو عمل کی طرح ہیں۔
لینکس کنٹینرز کسی نہ کسی طرح کی تنہائی فراہم کرتے ہیں، لیکن یہ اتنا مضبوط نہیں ہے جتنا کہ ورچوئل مشینوں کے ذریعے فراہم کیا جاتا ہے۔ جوہر میں، کنٹینر میں ایک عمل وہی عمل ہے جو میزبان آپریٹنگ سسٹم پر چلتا ہے۔
یہ سیکورٹی کا مسئلہ ہو سکتا ہے: یہ انتظام نظریاتی طور پر غیر متعلقہ ایپلی کیشنز کو ایک دوسرے کے ساتھ بات چیت کرنے کی اجازت دیتا ہے (یا تو جان بوجھ کر یا حادثاتی طور پر)۔
مزید برآں، Kubernetes کلسٹر میں تمام کام کا بوجھ کچھ کلسٹر وسیع خدمات کا اشتراک کرتا ہے جیسے - یہ ایپلی کیشنز کو کلسٹر میں دیگر ایپلی کیشنز کی خدمات تلاش کرنے کی اجازت دیتا ہے۔
درخواست کے حفاظتی تقاضوں کے لحاظ سے مذکورہ بالا تمام نکات کے مختلف معنی ہوسکتے ہیں۔
Kubernetes سیکورٹی کے مسائل کو روکنے کے لیے مختلف ٹولز مہیا کرتا ہے جیسے и . تاہم، انہیں درست طریقے سے ترتیب دینے کے لیے کچھ تجربے کی ضرورت ہوتی ہے؛ اس کے علاوہ، وہ تمام حفاظتی سوراخوں کو بالکل بند کرنے کے قابل نہیں ہیں۔
یہ ہمیشہ یاد رکھنا ضروری ہے کہ Kubernetes اصل میں اس کے لیے ڈیزائن کیا گیا تھا۔ اشتراک، کے لئے نہیں تنہائی اور حفاظت.
- سخت کثیر کرایہ داری کا فقدان
Kubernetes کلسٹر میں مشترکہ وسائل کی کثرت کو دیکھتے ہوئے، بہت سے طریقے ہیں کہ مختلف ایپلی کیشنز ایک دوسرے کی انگلیوں پر قدم رکھ سکتے ہیں۔
مثال کے طور پر، ایک ایپلیکیشن مشترکہ وسائل (جیسے سی پی یو یا میموری) پر اجارہ داری قائم کر سکتی ہے اور اسی نوڈ پر چلنے والی دیگر ایپلیکیشنز کو اس تک رسائی سے انکار کر سکتی ہے۔
Kubernetes اس رویے کو کنٹرول کرنے کے لیے مختلف میکانزم فراہم کرتا ہے، جیسے (مضمون بھی دیکھیں "" - تقریبا. ترجمہ), и . تاہم، جیسا کہ سیکورٹی کے معاملے میں، ان کی ترتیب کافی غیر معمولی ہے اور وہ بالکل تمام غیر متوقع ضمنی اثرات کو روکنے کے قابل نہیں ہیں۔
- صارفین کی بڑی تعداد
سنگل کلسٹر کی صورت میں، آپ کو بہت سے لوگوں تک اس تک رسائی کو کھولنا ہوگا۔ اور ان کی تعداد جتنی زیادہ ہوگی، اتنا ہی زیادہ خطرہ ہوگا کہ وہ کسی چیز کو "توڑ" دیں گے۔
کلسٹر کے اندر آپ کنٹرول کر سکتے ہیں کہ کون کیا استعمال کر سکتا ہے۔ (مضمون دیکھیں"" - تقریبا. ترجمہ). تاہم، یہ صارفین کو ان کی ذمہ داری کے علاقے کی حدود میں کسی چیز کو "توڑنے" سے نہیں روکے گا۔
- کلسٹرز غیر معینہ مدت تک نہیں بڑھ سکتے
تمام کام کے بوجھ کے لیے استعمال ہونے والا کلسٹر ممکنہ طور پر کافی بڑا ہوگا (نوڈس اور پوڈز کی تعداد کے لحاظ سے)۔
لیکن یہاں ایک اور مسئلہ پیدا ہوتا ہے: Kubernetes میں کلسٹرز غیر معینہ مدت تک نہیں بڑھ سکتے۔
کلسٹر سائز پر ایک نظریاتی حد ہے۔ Kubernetes میں یہ تقریبا ہے .
تاہم، حقیقی زندگی میں، مسائل بہت پہلے شروع ہو سکتے ہیں - مثال کے طور پر، صرف کے ساتھ .
حقیقت یہ ہے کہ بڑے جھرمٹ کبرنیٹس کنٹرول پرت پر زیادہ بوجھ رکھتے ہیں۔ دوسرے الفاظ میں، کلسٹر کو برقرار رکھنے اور مؤثر طریقے سے چلانے کے لیے محتاط ٹیوننگ کی ضرورت ہوتی ہے۔
اس مسئلے کو اصل بلاگ پر ایک متعلقہ مضمون میں تلاش کیا گیا ہے جسے "'.
لیکن آئیے مخالف نقطہ نظر پر غور کریں: بہت سے چھوٹے کلسٹرز۔
2. بہت سے چھوٹے، خصوصی کلسٹرز
اس نقطہ نظر کے ساتھ، آپ ہر ایک عنصر کے لیے الگ کلسٹر استعمال کرتے ہیں جو آپ تعینات کرتے ہیں:
بہت سے چھوٹے کلسٹرز
اس مضمون کے مقاصد کے لیے، ذیل میں قابل تعینات عنصر ایک ایپلیکیشن کی مثال سے مراد ہے - مثال کے طور پر، ایک علیحدہ ایپلیکیشن کا دیو ورژن۔
یہ حکمت عملی Kubernetes کو بطور خاص استعمال کرتی ہے۔ رن ٹائم انفرادی درخواست کی مثالوں کے لیے۔
آئیے اس نقطہ نظر کے فوائد اور نقصانات کو دیکھیں۔
+ محدود "دھماکے کا رداس"
جب ایک کلسٹر ناکام ہوجاتا ہے، تو منفی نتائج صرف ان کام کے بوجھ تک محدود ہوتے ہیں جو اس کلسٹر میں تعینات تھے۔ باقی تمام کام کا بوجھ اچھوت رہتا ہے۔
+ موصلیت
انفرادی کلسٹرز میں ہوسٹ کردہ ورک بوجھ وسائل کا اشتراک نہیں کرتے جیسے پروسیسر، میموری، آپریٹنگ سسٹم، نیٹ ورک، یا دیگر خدمات۔
نتیجہ غیر متعلقہ ایپلی کیشنز کے درمیان سخت تنہائی ہے، جو ان کی حفاظت کے لیے فائدہ مند ہو سکتا ہے۔
+ صارفین کی کم تعداد
یہ دیکھتے ہوئے کہ ہر کلسٹر میں کام کے بوجھ کا صرف ایک محدود سیٹ ہوتا ہے، اس تک رسائی والے صارفین کی تعداد کم ہو جاتی ہے۔
جتنے کم لوگ کلسٹر تک رسائی رکھتے ہیں، اتنا ہی کم خطرہ ہوتا ہے کہ کچھ "ٹوٹ جائے گا۔"
آئیے نقصانات کو دیکھتے ہیں۔
- وسائل کا غیر موثر استعمال
جیسا کہ پہلے ذکر کیا گیا ہے، ہر Kubernetes کلسٹر کو انتظامی وسائل کے ایک مخصوص سیٹ کی ضرورت ہوتی ہے: ماسٹر نوڈس، کنٹرول لیئر کے اجزاء، نگرانی اور لاگنگ کے حل۔
چھوٹے کلسٹرز کی ایک بڑی تعداد کی صورت میں، وسائل کا ایک بڑا حصہ انتظامیہ کے لیے مختص کیا جانا چاہیے۔
- مہنگا
وسائل کا غیر موثر استعمال خود بخود زیادہ اخراجات کا باعث بنتا ہے۔
مثال کے طور پر، ایک ہی کمپیوٹنگ پاور کے ساتھ تین کے بجائے 30 ماسٹر نوڈس کو برقرار رکھنے سے لاگت پر اثر پڑے گا۔
- انتظامیہ میں مشکلات
ایک سے زیادہ کبرنیٹس کلسٹرز کا انتظام کرنا صرف ایک کا انتظام کرنے سے کہیں زیادہ مشکل ہے۔
مثال کے طور پر، آپ کو ہر کلسٹر کے لیے تصدیق اور اجازت کو ترتیب دینا ہوگا۔ Kubernetes ورژن کو بھی کئی بار اپ ڈیٹ کرنا پڑے گا۔
ان تمام کاموں کو زیادہ موثر بنانے کے لیے آپ کو ممکنہ طور پر آٹومیشن استعمال کرنے کی ضرورت ہوگی۔
اب آئیے کم انتہائی منظرناموں کو دیکھیں۔
3. فی درخواست ایک کلسٹر
اس نقطہ نظر میں، آپ کسی خاص ایپلی کیشن کی تمام مثالوں کے لیے ایک الگ کلسٹر بناتے ہیں:
کلسٹر فی درخواست
اس راستے کو اصول کی عمومیت کے طور پر سمجھا جا سکتا ہے۔فی ٹیم الگ کلسٹرچونکہ عام طور پر انجینئرز کی ایک ٹیم ایک یا زیادہ ایپلی کیشنز تیار کر رہی ہوتی ہے۔
آئیے اس نقطہ نظر کے فوائد اور نقصانات کو دیکھیں۔
+ کلسٹر کو ایپلی کیشن میں ایڈجسٹ کیا جا سکتا ہے۔
اگر کسی ایپلیکیشن کی خصوصی ضروریات ہیں، تو انہیں دوسرے کلسٹرز کو متاثر کیے بغیر ایک کلسٹر میں لاگو کیا جا سکتا ہے۔
اس طرح کی ضروریات میں GPU کارکنان، بعض CNI پلگ ان، سروس میش، یا کوئی دوسری سروس شامل ہو سکتی ہے۔
ہر کلسٹر کو اس میں چلنے والی ایپلیکیشن کے مطابق بنایا جا سکتا ہے تاکہ اس میں صرف وہی موجود ہو جس کی ضرورت ہے۔
- ایک کلسٹر میں مختلف ماحول
اس نقطہ نظر کا نقصان یہ ہے کہ مختلف ماحول سے درخواست کی مثالیں ایک ہی کلسٹر میں ایک ساتھ رہتی ہیں۔
مثال کے طور پر، ایپلیکیشن کا پروڈ ورژن اسی کلسٹر میں چلتا ہے جیسا کہ ڈیو ورژن۔ اس کا مطلب یہ بھی ہے کہ ڈویلپرز اسی کلسٹر میں کام کرتے ہیں جس میں ایپلیکیشن کا پروڈکشن ورژن چلایا جاتا ہے۔
اگر، ڈیولپرز کی کارروائیوں یا ڈیو ورژن میں خرابیوں کی وجہ سے، کلسٹر میں کوئی ناکامی واقع ہوتی ہے، تو پروڈ ورژن کو بھی ممکنہ طور پر نقصان پہنچ سکتا ہے - اس نقطہ نظر کی ایک بہت بڑی خرابی۔
اور آخر کار، ہماری فہرست کا آخری منظر۔
4. فی ماحول ایک کلسٹر
اس منظر نامے میں ہر ماحول کے لیے الگ کلسٹر مختص کرنا شامل ہے:
ایک کلسٹر فی ماحول
مثال کے طور پر، آپ کے پاس کلسٹرز ہو سکتے ہیں۔ دیو, ٹیسٹ и پرو، جس میں آپ ایک مخصوص ماحول کے لیے وقف کردہ ایپلیکیشن کی تمام مثالیں چلائیں گے۔
یہاں اس نقطہ نظر کے فوائد اور نقصانات ہیں۔
+ پیداواری ماحول کی تنہائی
اس نقطہ نظر کے اندر، تمام ماحول ایک دوسرے سے الگ تھلگ ہیں۔ تاہم، عملی طور پر یہ ایک پیداواری ماحول میں خاص طور پر اہم ہے۔
ایپلیکیشن کے پروڈکشن ورژن اب اس سے آزاد ہیں جو دوسرے کلسٹرز اور ماحول میں ہو رہا ہے۔
اس طرح، اگر ڈیو کلسٹر میں اچانک کوئی مسئلہ پیدا ہو جاتا ہے، تو ایپلی کیشنز کے پروڈ ورژن ایسے کام کرتے رہیں گے جیسے کچھ ہوا ہی نہیں۔
+ کلسٹر کو ماحول میں ایڈجسٹ کیا جاسکتا ہے۔
ہر کلسٹر کو اس کے ماحول میں ایڈجسٹ کیا جا سکتا ہے۔ مثال کے طور پر، آپ کر سکتے ہیں:
- ڈیو کلسٹر میں ڈویلپمنٹ اور ڈیبگنگ کے لیے ٹولز انسٹال کریں۔
- کلسٹر میں ٹیسٹ فریم ورک اور ٹولز انسٹال کریں۔ ٹیسٹ;
- کلسٹر میں زیادہ طاقتور ہارڈویئر اور نیٹ ورک چینلز استعمال کریں۔ پرو.
یہ آپ کو ایپلیکیشن ڈویلپمنٹ اور آپریشن دونوں کی کارکردگی کو بڑھانے کی اجازت دیتا ہے۔
+ پروڈکشن کلسٹر تک رسائی کو محدود کرنا
پروڈ کلسٹر کے ساتھ براہ راست کام کرنے کی ضرورت شاذ و نادر ہی پیدا ہوتی ہے، لہذا آپ ان لوگوں کے حلقے کو نمایاں طور پر محدود کر سکتے ہیں جن کی اس تک رسائی ہے۔
آپ اس سے بھی آگے جا سکتے ہیں اور لوگوں کو اس کلسٹر تک رسائی سے یکسر انکار کر سکتے ہیں، اور خودکار CI/CD ٹول کا استعمال کرتے ہوئے تمام تعیناتیاں کر سکتے ہیں۔ اس طرح کا نقطہ نظر انسانی غلطیوں کے خطرے کو بالکل کم کر دے گا جہاں یہ سب سے زیادہ متعلقہ ہے۔
اور اب نقصانات کے بارے میں چند الفاظ۔
- درخواستوں کے درمیان کوئی الگ تھلگ نہیں۔
نقطہ نظر کا بنیادی نقصان ایپلی کیشنز کے درمیان ہارڈ ویئر اور وسائل کی تنہائی کی کمی ہے۔
غیر متعلقہ ایپلی کیشنز کلسٹر وسائل کا اشتراک کرتی ہیں: سسٹم کور، پروسیسر، میموری، اور کچھ دیگر خدمات۔
جیسا کہ ذکر کیا گیا ہے، یہ ممکنہ طور پر خطرناک ہو سکتا ہے۔
- درخواست کے انحصار کو مقامی بنانے میں ناکامی۔
اگر کسی درخواست کی خصوصی ضروریات ہیں، تو ان کا تمام کلسٹرز میں مطمئن ہونا ضروری ہے۔
مثال کے طور پر، اگر کسی ایپلیکیشن کو GPU کی ضرورت ہوتی ہے، تو ہر کلسٹر میں GPU کے ساتھ کم از کم ایک کارکن ہونا چاہیے (چاہے یہ صرف اسی ایپلی کیشن کے ذریعہ استعمال کیا گیا ہو)۔
نتیجے کے طور پر، ہمیں زیادہ اخراجات اور وسائل کے غیر موثر استعمال کا خطرہ ہے۔
حاصل يہ ہوا
اگر آپ کے پاس ایپلی کیشنز کا ایک مخصوص سیٹ ہے، تو انہیں کئی بڑے کلسٹرز یا بہت سے چھوٹے کلسٹرز میں رکھا جا سکتا ہے۔
مضمون میں مختلف طریقوں کے فوائد اور نقصانات پر بحث کی گئی ہے، جس میں ایک عالمی کلسٹر سے لے کر کئی چھوٹے اور انتہائی مہارت والے ہیں:
- ایک بڑا جنرل کلسٹر؛
- بہت سے چھوٹے انتہائی خصوصی کلسٹرز؛
- فی درخواست ایک کلسٹر؛
- ایک کلسٹر فی ماحول۔
تو آپ کو کون سا طریقہ اختیار کرنا چاہئے؟
ہمیشہ کی طرح، جواب کا انحصار استعمال کے معاملے پر ہوتا ہے: آپ کو مختلف طریقوں کے فوائد اور نقصانات کا وزن کرنا ہوگا اور بہترین آپشن کا انتخاب کرنا ہوگا۔
تاہم، انتخاب مندرجہ بالا مثالوں تک محدود نہیں ہے - آپ ان میں سے کسی بھی مرکب کو استعمال کر سکتے ہیں!
مثال کے طور پر، آپ ہر ٹیم کے لیے چند کلسٹرز کو منظم کر سکتے ہیں: ایک ترقیاتی کلسٹر (جس میں ماحولیات ہوں گے دیو и ٹیسٹ) اور کلسٹر کے لیے پیداوار (جہاں پیداواری ماحول واقع ہو گا)۔
اس آرٹیکل میں دی گئی معلومات کی بنیاد پر، آپ کسی خاص منظر نامے کے مطابق فوائد اور نقصانات کو بہتر بنا سکتے ہیں۔ اچھی قسمت!
PS
ہمارے بلاگ پر بھی پڑھیں:
- «؛ "
- «؛ "
- «؛ "
- «'.
ماخذ: www.habr.com