Kubernetes: اوپن سورس بمقابلہ وینڈر مخصوص

ہیلو، میرا نام دمتری کراسنوف ہے۔ میں پانچ سال سے زیادہ عرصے سے Kubernetes کلسٹرز کا انتظام کر رہا ہوں اور پیچیدہ مائیکرو سروس آرکیٹیکچر بنا رہا ہوں۔ اس سال کے آغاز میں، ہم نے کنٹینرم پر مبنی Kubernetes کلسٹرز کے انتظام کے لیے ایک سروس شروع کی۔ اس موقع کو لے کر، میں آپ کو بتاؤں گا کہ Kubernetes کیا ہے اور وینڈر کے ساتھ انضمام اوپن سورس سے کیسے مختلف ہے۔

کے ساتھ شروع کرنے کے لئے، کیا ہے Kubernetes. یہ میزبانوں کی ایک بڑی تعداد پر کنٹینرز کا انتظام کرنے کا نظام ہے۔ یونانی سے، ویسے، اس کا ترجمہ "پائلٹ" یا "ہیلمسمین" کے طور پر کیا جاتا ہے۔ اصل میں Google کی طرف سے تیار کیا گیا اور پھر Cloud Native Computing Foundation، ایک بین الاقوامی غیر منافع بخش تنظیم کو ٹیکنالوجی کے تعاون کے طور پر عطیہ کیا گیا جو دنیا کے سرکردہ ڈویلپرز، اختتامی صارفین اور کنٹینر ٹیکنالوجی فراہم کرنے والوں کو اکٹھا کرتا ہے۔

کنٹینرز کی ایک بڑی تعداد کا انتظام کریں

آئیے اب اندازہ لگاتے ہیں کہ یہ کنٹینرز کس قسم کے ہیں۔ یہ اپنے پورے ماحول کے ساتھ ایک ایپلی کیشن ہے - بنیادی طور پر وہ لائبریریاں جن پر پروگرام کا انحصار ہے۔ یہ سب آرکائیوز میں پیک کیا جاتا ہے اور ایک تصویر کی شکل میں پیش کیا جاتا ہے جسے آپریٹنگ سسٹم، ٹیسٹ اور بہت کچھ سے قطع نظر چلایا جا سکتا ہے۔ لیکن ایک مسئلہ ہے - میزبانوں کی ایک بڑی تعداد پر کنٹینرز کا انتظام بہت مشکل ہے۔ اسی لیے کوبرنیٹس بنایا گیا تھا۔

کنٹینر کی تصویر کسی ایپلیکیشن کے علاوہ اس کے انحصار کی نمائندگی کرتی ہے۔ ایپلیکیشن، اس کا انحصار، اور OS فائل سسٹم امیج امیج کے مختلف حصوں میں واقع ہیں، نام نہاد پرتیں۔ پرتوں کو مختلف کنٹینرز کے لیے دوبارہ استعمال کیا جا سکتا ہے۔ مثال کے طور پر، کسی کمپنی میں تمام ایپلیکیشنز Ubuntu بیس لیئر کا استعمال کر سکتی ہیں۔ کنٹینرز چلاتے وقت، میزبان پر ایک ہی بیس لیئر کی متعدد کاپیاں ذخیرہ کرنے کی ضرورت نہیں ہے۔ یہ آپ کو امیج اسٹوریج اور ڈیلیوری کو بہتر بنانے کی اجازت دیتا ہے۔

جب ہم کسی کنٹینر سے ایپلیکیشن چلانا چاہتے ہیں تو ضروری پرتیں ایک دوسرے پر لگائی جاتی ہیں اور ایک اوورلے فائل سسٹم بنتا ہے۔ ایک ریکارڈنگ پرت اوپر رکھی جاتی ہے، جو کنٹینر کے رک جانے پر ہٹا دی جاتی ہے۔ یہ اس بات کو یقینی بناتا ہے کہ جب کنٹینر چلتا ہے، تو ایپلیکیشن میں ہمیشہ وہی ماحول ہوتا ہے، جسے تبدیل نہیں کیا جا سکتا۔ یہ مختلف میزبان OS پر ماحول کی تولیدی صلاحیت کی ضمانت دیتا ہے۔ چاہے وہ Ubuntu ہو یا CentOS، ماحول ہمیشہ ایک جیسا رہے گا۔ اس کے علاوہ، لینکس کرنل میں بنائے گئے میکانزم کا استعمال کرتے ہوئے کنٹینر کو میزبان سے الگ کر دیا جاتا ہے۔ کنٹینر میں موجود ایپلی کیشنز فائلوں، میزبان کے عمل اور پڑوسی کنٹینرز کو نہیں دیکھتی ہیں۔ میزبان OS سے ایپلی کیشنز کی یہ تنہائی سیکیورٹی کی ایک اضافی پرت فراہم کرتی ہے۔

میزبان پر کنٹینرز کا انتظام کرنے کے لیے بہت سے ٹولز دستیاب ہیں۔ ان میں سب سے زیادہ مقبول ڈوکر ہے۔ یہ آپ کو کنٹینرز کا مکمل لائف سائیکل فراہم کرنے کی اجازت دیتا ہے۔ تاہم، یہ صرف ایک میزبان پر کام کرتا ہے۔ اگر آپ کو متعدد میزبانوں میں کنٹینرز کا انتظام کرنے کی ضرورت ہے تو، ڈوکر انجینئرز کی زندگی کو جہنم بنا سکتا ہے۔ اسی لیے کوبرنیٹس بنایا گیا تھا۔

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

شکل 1. کبرنیٹس کے کام کرنے کے طریقے کی منصوبہ بندی کی نمائندگی

مکمل آٹومیشن

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

Kubernetes کے ساتھ مل کر، DevOps آپ کو اس عمل کو خودکار کرنے کی اجازت دیتا ہے تاکہ یہ عملاً خود ڈویلپرز کی شرکت کے بغیر ہو۔ اس کی وجہ سے، تعمیر نمایاں طور پر تیز ہے، کیونکہ ڈویلپر کو اپنے کمپیوٹر پر ایسا کرنے کی ضرورت نہیں ہے - وہ صرف کوڈ کا ایک ٹکڑا لکھتا ہے، کوڈ کو ذخیرہ میں دھکیلتا ہے، جس کے بعد پائپ لائن شروع کی جاتی ہے، جس میں عمل شامل ہوسکتا ہے. تعمیر، جانچ، اور رول آؤٹ کا۔ اور یہ ہر عہد کے ساتھ ہوتا ہے، لہذا جانچ مسلسل ہوتی رہتی ہے۔

ایک ہی وقت میں، کنٹینر کا استعمال آپ کو اس بات کا یقین کرنے کی اجازت دیتا ہے کہ اس پروگرام کے پورے ماحول کو بالکل اسی شکل میں پیداوار میں جاری کیا جائے گا جس میں اس کا تجربہ کیا گیا تھا۔ یعنی، کوئی مسئلہ نہیں ہوگا جیسے "کچھ ورژن ٹیسٹ میں تھے، دوسرے پروڈکشن میں، لیکن جب ہم نے انہیں انسٹال کیا تو سب کچھ گر گیا۔" اور آج سے ہمارا رجحان مائیکرو سروس آرکیٹیکچر کی طرف ہے، جب ایک بڑی ایپلی کیشن کے بجائے سینکڑوں چھوٹی ایپلی کیشنز ہیں، ان کو دستی طور پر چلانے کے لیے، ملازمین کے ایک بڑے عملے کی ضرورت ہوگی۔ اسی لیے ہم Kubernetes استعمال کرتے ہیں۔

پیشہ، پیشہ، پیشہ

اگر ہم ایک پلیٹ فارم کے طور پر Kubernetes کے فوائد کے بارے میں بات کرتے ہیں، تو اس کے ایک مائیکرو سروس فن تعمیر کے انتظام کے نقطہ نظر سے اہم فوائد ہیں۔

• متعدد نقلوں کا انتظام کرنا۔ سب سے اہم چیز متعدد میزبانوں میں کنٹینرز کا انتظام کرنا ہے۔ زیادہ اہم بات یہ ہے کہ کنٹینرز میں ایک ہی ہستی کے طور پر متعدد ایپلیکیشن ریپلیکس کا نظم کریں۔ اس کا شکریہ، انجینئرز کو ہر ایک کنٹینر کے بارے میں فکر کرنے کی ضرورت نہیں ہے. اگر کنٹینرز میں سے ایک کریش ہو جاتا ہے، تو Kubernetes اسے دیکھے گا اور اسے دوبارہ شروع کر دے گا۔
• کلسٹر نیٹ ورک۔ Kubernetes کے پاس ایک نام نہاد کلسٹر نیٹ ورک بھی ہے جس کی اپنی ایڈریس اسپیس ہے۔ اس کی بدولت ہر پوڈ کا اپنا پتہ ہوتا ہے۔ ایک ذیلی پوڈ کو کلسٹر کی کم از کم ساختی اکائی کے طور پر سمجھا جاتا ہے جس میں کنٹینرز کو براہ راست لانچ کیا جاتا ہے۔ اس کے علاوہ، Kubernetes میں فعالیت ہے جو لوڈ بیلنس اور سروس ڈسکوری کو یکجا کرتی ہے۔ یہ آپ کو دستی IP ایڈریس مینجمنٹ سے چھٹکارا حاصل کرنے اور اس کام کو Kubernetes کو سونپنے کی اجازت دیتا ہے۔ اور خودکار صحت کی جانچ سے مسائل کا پتہ لگانے میں مدد ملے گی اور ٹریفک کو کام کرنے والے پوڈز پر بھیج دیا جائے گا۔
• کنفیگریشن مینجمنٹ۔ ایپلیکیشنز کی ایک بڑی تعداد کا انتظام کرتے وقت، ایپلیکیشن کنفیگریشن کا انتظام کرنا مشکل ہو جاتا ہے۔ اس مقصد کے لیے Kubernetes کے پاس خصوصی ConfigMap وسائل ہیں۔ وہ آپ کو کنفیگریشنز کو مرکزی طور پر اسٹور کرنے اور ایپلیکیشنز چلاتے وقت ان کو پوڈز کے سامنے لانے کی اجازت دیتے ہیں۔ یہ طریقہ کار ہمیں کم از کم دس یا سو ایپلیکیشن ریپلیکس میں کنفیگریشن کی مستقل مزاجی کی ضمانت دیتا ہے۔
• مستقل حجم۔ کنٹینرز فطری طور پر ناقابل تغیر ہوتے ہیں اور جب کنٹینر کو روک دیا جاتا ہے، تو فائل سسٹم میں لکھا گیا تمام ڈیٹا تباہ ہو جائے گا۔ لیکن کچھ ایپلیکیشنز ڈیٹا کو براہ راست ڈسک پر اسٹور کرتی ہیں۔ اس مسئلے کو حل کرنے کے لیے، Kubernetes میں ڈسک اسٹوریج مینجمنٹ کی فعالیت ہے - مستقل حجم۔ یہ طریقہ کار ڈیٹا کے لیے بیرونی اسٹوریج کا استعمال کرتا ہے اور مستقل اسٹوریج، بلاک یا فائل کو کنٹینرز میں منتقل کر سکتا ہے۔ یہ حل آپ کو ورکرز سے الگ الگ ڈیٹا اسٹور کرنے کی اجازت دیتا ہے، جو انہی ورکرز کے ٹوٹ جانے کی صورت میں انہیں بچاتا ہے۔
• لوڈ بیلنسر۔ اگرچہ Kubernetes میں ہم تجریدی اداروں کا نظم کرتے ہیں جیسے کہ تعیناتی، StatefulSet، وغیرہ، بالآخر کنٹینرز باقاعدہ ورچوئل مشینوں یا ہارڈ ویئر سرورز پر چلتے ہیں۔ وہ کامل نہیں ہیں اور کسی بھی وقت گر سکتے ہیں۔ Kubernetes اسے دیکھے گا اور اندرونی ٹریفک کو دوسری نقلوں پر بھیج دے گا۔ لیکن باہر سے آنے والی ٹریفک کا کیا کریں؟ اگر آپ ٹریفک کو کسی کارکن کی طرف بھیجتے ہیں، اگر یہ کریش ہو جاتا ہے، تو سروس دستیاب نہیں ہو جائے گی۔ اس مسئلے کو حل کرنے کے لیے Kubernetes کے پاس لوڈ بیلنسر جیسی خدمات ہیں۔ وہ کلسٹر میں تمام کارکنوں کے لیے ایک بیرونی کلاؤڈ بیلنسر کو خودکار طور پر ترتیب دینے کے لیے ڈیزائن کیا گیا ہے۔ یہ بیرونی توازن کار بیرونی ٹریفک کو کارکنوں کی طرف لے جاتا ہے اور خود ان کی حیثیت کی نگرانی کرتا ہے۔ اگر ایک یا زیادہ کارکن دستیاب نہیں ہوتے ہیں، تو ٹریفک کو دوسروں کی طرف بھیج دیا جاتا ہے۔ یہ آپ کو Kubernetes کا استعمال کرتے ہوئے انتہائی دستیاب خدمات تخلیق کرنے کی اجازت دیتا ہے۔

مائیکرو سروس آرکیٹیکچرز چلاتے وقت Kubernetes بہترین کام کرتا ہے۔ کلاسیکی فن تعمیر میں نظام کو نافذ کرنا ممکن ہے، لیکن یہ بے معنی ہے۔ اگر ایک ایپلیکیشن متعدد نقلوں پر نہیں چل سکتی، تو اس سے کیا فرق پڑتا ہے - کبرنیٹس میں یا نہیں؟

اوپن سورس کبرنیٹس

اوپن سورس کبرنیٹس ایک زبردست چیز ہے: میں نے اسے انسٹال کیا اور یہ کام کرتا ہے۔ آپ اسے اپنے ہارڈویئر سرورز پر، اپنے انفراسٹرکچر پر تعینات کر سکتے ہیں، ماسٹرز اور ورکرز انسٹال کر سکتے ہیں جن پر تمام ایپلیکیشنز چلیں گی۔ اور سب سے اہم بات یہ ہے کہ یہ سب مفت ہے۔ تاہم، باریکیاں ہیں.

• سب سے پہلے منتظمین اور انجینئروں کے علم اور تجربے کا مطالبہ ہے جو اس سب کو تعینات اور معاونت کریں گے۔ چونکہ کلسٹر کو کلسٹر میں عمل کی مکمل آزادی حاصل ہے، اس لیے وہ خود کلسٹر کی کارکردگی کا ذمہ دار ہے۔ اور یہاں ہر چیز کو توڑنا بہت آسان ہے۔
• دوسرا انضمام کا فقدان ہے۔ اگر آپ مقبول ورچوئلائزیشن پلیٹ فارم کے بغیر Kubernetes چلاتے ہیں، تو آپ کو پروگرام کے تمام فوائد حاصل نہیں ہوں گے۔ جیسے پرسسٹنٹ والیوم اور لوڈ بیلنس سروسز کا استعمال۔

شکل 2. k8s فن تعمیر

فروش سے Kubernetes

کلاؤڈ فراہم کنندہ کے ساتھ انضمام دو اختیارات فراہم کرتا ہے:

• سب سے پہلے، ایک شخص صرف "کلسٹر بنائیں" کے بٹن پر کلک کر کے پہلے سے ترتیب شدہ اور استعمال کے لیے تیار کلسٹر حاصل کر سکتا ہے۔
• دوسرا، وینڈر خود کلسٹر انسٹال کرتا ہے اور کلاؤڈ کے ساتھ انضمام قائم کرتا ہے۔

یہ یہاں کیسے ہوتا ہے۔ انجینئر جو کلسٹر شروع کرتا ہے وہ بتاتا ہے کہ اسے کتنے کارکنوں کی ضرورت ہے اور کن پیرامیٹرز کے ساتھ (مثال کے طور پر، 5 ورکرز، ہر ایک کے پاس 10 سی پی یو، 16 جی بی ریم اور 100 جی بی ڈسک)۔ جس کے بعد اسے پہلے سے بنائے گئے کلسٹر تک رسائی حاصل ہو جاتی ہے۔ اس صورت میں، جن کارکنوں پر لوڈ شروع کیا جاتا ہے وہ مکمل طور پر کلائنٹ کو منتقل کر دیے جاتے ہیں، لیکن پورا انتظامی طیارہ وینڈر کی ذمہ داری کے تحت رہتا ہے (اگر سروس منظم سروس ماڈل کے مطابق فراہم کی جاتی ہے)۔

تاہم، اس اسکیم کی اپنی خامیاں ہیں۔ اس حقیقت کی وجہ سے کہ انتظامی طیارہ وینڈر کے پاس رہتا ہے، وینڈر کلائنٹ کو مکمل رسائی نہیں دیتا، اور یہ Kubernetes کے ساتھ کام کرنے میں لچک کو کم کرتا ہے۔ کبھی کبھی ایسا ہوتا ہے کہ ایک کلائنٹ Kubernetes میں کچھ مخصوص فعالیت شامل کرنا چاہتا ہے، مثال کے طور پر، LDAP کے ذریعے تصدیق، لیکن انتظامی جہاز کی ترتیب اس کی اجازت نہیں دیتی۔

شکل 3۔ کلاؤڈ فراہم کرنے والے سے Kubernetes کلسٹر کی مثال

کیا منتخب کرنا ہے: اوپن سورس یا وینڈر

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

ٹھیک ہے، پیشہ واضح ہیں، نقصانات بھی معلوم ہیں. ایک چیز مستقل ہے: Kubernetes بہت سے کنٹینرز کے انتظام کو خودکار کر کے بہت سارے مسائل حل کرتا ہے۔ اور کون سا انتخاب کرنا ہے، اوپن سورس یا وینڈر - ہر کوئی اپنا فیصلہ خود کرتا ہے۔

یہ مضمون #CloudMTS فراہم کنندہ کی کنٹینرم سروس کے معروف معمار، دمتری کراسنوف نے تیار کیا تھا۔

ماخذ: www.habr.com