جیسے جیسے آپ زیادہ سے زیادہ Kubernetes سروسز بنانا شروع کرتے ہیں، ابتدائی طور پر آسان کام زیادہ پیچیدہ ہونے لگتے ہیں۔ مثال کے طور پر، ترقیاتی ٹیمیں اسی نام سے خدمات یا تعیناتیاں نہیں بنا سکتیں۔ اگر آپ کے پاس ہزاروں پوڈز ہیں، تو ان کی فہرست بنانے میں کافی وقت لگے گا، ان کا صحیح طریقے سے انتظام کرنے کو چھوڑ دیں۔ اور یہ آئس برگ کا صرف ایک سرہ ہے۔
آئیے دیکھتے ہیں کہ کس طرح نام کی جگہ کبرنیٹس کے وسائل کو منظم کرنا آسان بناتی ہے۔ تو نام کی جگہ کیا ہے؟ Namespace کو آپ کے Kubernetes کلسٹر کے اندر ایک ورچوئل کلسٹر کے طور پر سوچا جا سکتا ہے۔ آپ ایک ہی Kubernetes کلسٹر کے اندر متعدد نام کی جگہیں ایک دوسرے سے الگ کر سکتے ہیں۔ وہ تنظیم، سیکورٹی، اور یہاں تک کہ سسٹم کی کارکردگی کے ساتھ آپ کی اور آپ کی ٹیموں کی واقعی مدد کر سکتے ہیں۔
کبرنیٹس کی زیادہ تر تقسیموں پر، کلسٹر باکس سے باہر نکلتا ہے جس میں "ڈیفالٹ" نام کی جگہ ہے۔ اصل میں تین نام کی جگہیں ہیں جن سے Kubernetes ڈیل کرتا ہے: ڈیفالٹ، کیوب سسٹم، اور کیوب پبلک۔ فی الحال، Kube-public اکثر استعمال نہیں ہوتا ہے۔
کیوب نام کی جگہ کو اکیلا چھوڑنا ایک اچھا خیال ہے، خاص طور پر Google Kubernetes Engine جیسے منظم نظام پر۔ یہ "پہلے سے طے شدہ" نام کی جگہ کو اس جگہ کے طور پر استعمال کرتا ہے جہاں آپ کی خدمات اور ایپلیکیشنز بنتی ہیں۔ اس میں کوئی خاص بات نہیں ہے، سوائے اس کے کہ Kubernetes اسے استعمال کرنے کے لیے باکس سے باہر ترتیب دیا گیا ہے، اور آپ اسے ہٹا نہیں سکتے۔ یہ شروع کرنے اور کم کارکردگی والے نظاموں کے لیے بہت اچھا ہے، لیکن میں بڑے پروڈ سسٹمز پر ڈیفالٹ نام کی جگہ استعمال کرنے کی سفارش نہیں کروں گا۔ مؤخر الذکر صورت میں، ایک ترقیاتی ٹیم آسانی سے کسی اور کے کوڈ کو دوبارہ لکھ سکتی ہے اور دوسری ٹیم کے کام کو سمجھے بغیر بھی اسے توڑ سکتی ہے۔
اس لیے، آپ کو متعدد نام کی جگہیں بنانا چاہیے اور اپنی خدمات کو قابل انتظام یونٹس میں تقسیم کرنے کے لیے ان کا استعمال کرنا چاہیے۔ ایک ہی کمانڈ سے نام کی جگہ بنائی جا سکتی ہے۔ اگر آپ ٹیسٹ کے نام سے نام کی جگہ بنانا چاہتے ہیں، تو کمانڈ استعمال کریں $kubectl create namespace test یا صرف YAML فائل بنائیں اور اسے کسی دوسرے Kubernetes وسائل کی طرح استعمال کریں۔
آپ $kubectl get namespace کمانڈ استعمال کرکے تمام نام کی جگہیں دیکھ سکتے ہیں۔
ایک بار یہ ہو جانے کے بعد، آپ کو تین بلٹ ان نیم اسپیس اور "ٹیسٹ" نامی ایک نئی نام کی جگہ نظر آئے گی۔ آئیے پوڈ بنانے کے لیے ایک سادہ YAML فائل کو دیکھتے ہیں۔ آپ دیکھیں گے کہ نام کی جگہ کا کوئی ذکر نہیں ہے۔
اگر آپ اس فائل کو چلانے کے لیے kubectl استعمال کرتے ہیں، تو یہ فی الحال فعال نام کی جگہ میں mypod ماڈیول بنائے گا۔ جب تک آپ اسے تبدیل نہیں کرتے یہ پہلے سے طے شدہ نام کی جگہ ہوگی۔ Kubernetes کو یہ بتانے کے 2 طریقے ہیں کہ آپ اپنے وسائل کو کس نام کی جگہ بنانا چاہتے ہیں۔ پہلا طریقہ یہ ہے کہ وسیلہ بناتے وقت نام کی جگہ کا جھنڈا استعمال کیا جائے۔
دوسرا طریقہ YAML اعلامیہ میں نام کی جگہ کی وضاحت کرنا ہے۔
اگر آپ YAML میں نام کی جگہ بتاتے ہیں، تو وسائل ہمیشہ اس نام کی جگہ میں بنائے جائیں گے۔ اگر آپ نام کی جگہ کا پرچم استعمال کرتے ہوئے مختلف نام کی جگہ استعمال کرنے کی کوشش کرتے ہیں، تو کمانڈ ناکام ہو جائے گی۔ اب اگر آپ اپنی پھلی تلاش کرنے کی کوشش کریں گے تو آپ ایسا نہیں کر پائیں گے۔
ایسا اس لیے ہوتا ہے کیونکہ تمام کمانڈز فی الحال فعال نام کی جگہ سے باہر کی جاتی ہیں۔ اپنے پوڈ کو تلاش کرنے کے لیے، آپ کو نام کی جگہ کا جھنڈا استعمال کرنے کی ضرورت ہے، لیکن یہ تیزی سے بور ہو جاتا ہے، خاص طور پر اگر آپ کسی ٹیم کے ڈویلپر ہیں جو اپنی نام کی جگہ استعمال کرتی ہے اور ہر ایک کمانڈ کے لیے اس پرچم کو استعمال نہیں کرنا چاہتی۔ آئیے دیکھتے ہیں کہ ہم اسے کیسے ٹھیک کر سکتے ہیں۔
باکس سے باہر، آپ کے فعال نام کی جگہ کو ڈیفالٹ کہا جاتا ہے۔ اگر آپ وسائل YAML میں نام کی جگہ کی وضاحت نہیں کرتے ہیں، تو تمام Kubernetes کمانڈز اس فعال ڈیفالٹ نام کی جگہ استعمال کریں گی۔ بدقسمتی سے، kubectl کا استعمال کرتے ہوئے فعال نام کی جگہ کو منظم کرنے کی کوشش ناکام ہو سکتی ہے۔ تاہم، کیوبنس نامی ایک بہت اچھا ٹول ہے جو اس عمل کو بہت آسان بنا دیتا ہے۔ جب آپ kubens کمانڈ چلاتے ہیں، تو آپ کو تمام نام کی جگہیں نظر آتی ہیں جن میں فعال نام کی جگہ نمایاں ہوتی ہے۔
فعال نام کی جگہ کو ٹیسٹ نام کی جگہ میں تبدیل کرنے کے لیے، آپ صرف $kubens test کمانڈ چلاتے ہیں۔ اگر آپ پھر $kubens کمانڈ کو دوبارہ چلاتے ہیں، تو آپ دیکھیں گے کہ اب ایک نئی فعال نام کی جگہ مختص کی گئی ہے - test۔
اس کا مطلب ہے کہ آپ کو ٹیسٹ نام کی جگہ میں پوڈ دیکھنے کے لیے نام کی جگہ کے جھنڈے کی ضرورت نہیں ہے۔
اس طرح نام کی جگہیں ایک دوسرے سے پوشیدہ ہیں، لیکن ایک دوسرے سے الگ نہیں ہیں۔ ایک نام کی جگہ میں ایک سروس دوسرے نام کی جگہ میں ایک سروس کے ساتھ بہت آسانی سے بات چیت کر سکتی ہے، جو اکثر بہت مفید ہوتی ہے۔ مختلف نام کی جگہوں پر بات چیت کرنے کی اہلیت کا مطلب یہ ہے کہ آپ کے ڈویلپرز کی سروس کسی دوسری ڈیو ٹیم کی سروس کے ساتھ مختلف نام کی جگہ میں بات چیت کر سکتی ہے۔
عام طور پر، جب آپ کی ایپلیکیشن کسی Kubernetes سروس تک رسائی حاصل کرنا چاہتی ہے، تو آپ بلٹ ان DNS دریافت سروس استعمال کرتے ہیں اور اپنی ایپلیکیشن کو سروس کا نام دیتے ہیں۔ تاہم، ایسا کرنے سے، آپ ایک سے زیادہ نام کی جگہوں پر ایک ہی نام سے ایک سروس بنا سکتے ہیں، جو قابل قبول نہیں ہے۔
خوش قسمتی سے، DNS ایڈریس کی توسیع شدہ شکل کا استعمال کرتے ہوئے اس کے ارد گرد حاصل کرنے کے لئے آسان ہے. Kubernetes میں خدمات ایک عام DNS ٹیمپلیٹ کا استعمال کرتے ہوئے اپنے اختتامی نقطوں کو ظاہر کرتی ہیں۔ یہ کچھ اس طرح لگتا ہے:
عام طور پر، آپ کو صرف سروس کے نام کی ضرورت ہوتی ہے اور DNS خود بخود مکمل پتہ کا تعین کرے گا۔
تاہم، اگر آپ کو کسی مختلف نام کی جگہ میں کسی سروس تک رسائی حاصل کرنے کی ضرورت ہے، تو صرف خدمت کے نام کے علاوہ نام کی جگہ کا نام استعمال کریں:
مثال کے طور پر، اگر آپ ٹیسٹ نام کی جگہ میں سروس ڈیٹا بیس سے منسلک ہونا چاہتے ہیں، تو آپ ایڈریس ڈیٹا بیس database.test استعمال کر سکتے ہیں۔
اگر آپ پروڈ نام کی جگہ میں سروس ڈیٹا بیس سے منسلک ہونا چاہتے ہیں، تو آپ database.prod استعمال کرتے ہیں۔
اگر آپ واقعی نام کی جگہ تک رسائی کو الگ تھلگ اور محدود کرنا چاہتے ہیں، تو Kubernetes آپ کو Kubernetes نیٹ ورک پالیسیوں کا استعمال کرتے ہوئے ایسا کرنے کی اجازت دیتا ہے۔ اس پر اگلی قسط میں بات کروں گا۔
مجھ سے اکثر یہ سوال پوچھا جاتا ہے کہ مجھے کتنے نام کی جگہیں اور کس مقصد کے لیے بنانا چاہیے؟ ڈیٹا کا ایک منظم ٹکڑا کیا ہے؟
اگر آپ بہت زیادہ نام کی جگہیں بناتے ہیں، تو وہ آپ کے راستے میں آ جائیں گے۔ اگر ان میں سے بہت کم ہیں، تو آپ اس طرح کے حل کے تمام فوائد سے محروم ہوجائیں گے۔ میرے خیال میں چار اہم مراحل ہیں جن سے ہر کمپنی اپنا تنظیمی ڈھانچہ بناتے وقت گزرتی ہے۔ ترقی کے اس مرحلے پر منحصر ہے کہ آپ کا پروجیکٹ یا کمپنی جس میں ہے، آپ مناسب نام کی جگہ کی حکمت عملی اختیار کرنا چاہیں گے۔
تصور کریں کہ آپ ایک چھوٹی ٹیم کا حصہ ہیں جو 5-10 مائیکرو سروسز تیار کرنے پر کام کر رہی ہے اور آپ تمام ڈویلپرز کو آسانی سے ایک کمرے میں جمع کر سکتے ہیں۔ اس صورت حال میں، تمام پروڈ سروسز کو ڈیفالٹ نام کی جگہ میں چلانا سمجھ میں آتا ہے۔ یقیناً، مزید لچک کے لیے، آپ 2 نام کی جگہیں استعمال کر سکتے ہیں - پروڈ اور دیو کے لیے الگ۔ اور غالباً، آپ اپنے مقامی کمپیوٹر پر Minikube جیسی کوئی چیز استعمال کرکے اپنی ترقی کی جانچ کرتے ہیں۔
آئیے کہتے ہیں کہ چیزیں بدل رہی ہیں اور اب آپ کے پاس تیزی سے ترقی کرنے والی ٹیم ہے جو ایک وقت میں 10 سے زیادہ مائیکرو سروسز پر کام کر رہی ہے۔ ایک وقت ایسا آتا ہے جب پروڈ اور دیو کے لیے الگ الگ کئی کلسٹرز یا نام کی جگہیں استعمال کرنا ضروری ہوتا ہے۔ آپ ٹیم کو کئی ذیلی ٹیموں میں توڑ سکتے ہیں تاکہ ان میں سے ہر ایک کی اپنی مائیکرو سروسز ہوں اور ان ٹیموں میں سے ہر ایک سافٹ ویئر کی ترقی اور ریلیز کے انتظام کے عمل کو آسان بنانے کے لیے اپنی نام کی جگہ کا انتخاب کر سکے۔
چونکہ ٹیم کا ہر رکن اس بات کی بصیرت حاصل کرتا ہے کہ سسٹم کس طرح مجموعی طور پر کام کرتا ہے، ہر تبدیلی کو دوسرے تمام ڈویلپرز کے ساتھ مربوط کرنا مشکل تر ہوتا چلا جاتا ہے۔ آپ کی مقامی مشین پر مکمل اسٹیک بنانے کی کوشش کرنا دن بدن مشکل ہوتا جا رہا ہے۔
بڑی کمپنیوں میں، ڈویلپرز کو عام طور پر معلوم نہیں ہوتا کہ کون کس چیز پر کام کر رہا ہے۔ ٹیمیں سروس کنٹریکٹس کا استعمال کرتے ہوئے مواصلت کرتی ہیں یا سروس میش ٹیکنالوجی کا استعمال کرتی ہیں، جو نیٹ ورک پر ایک تجریدی پرت کا اضافہ کرتی ہے، جیسے اسٹیو کنفیگریشن ٹول۔ مقامی طور پر پورے اسٹیک کو چلانے کی کوشش کرنا ممکن نہیں ہے۔ لہذا، ایک نقطہ آتا ہے جہاں ہر کمانڈ کو یقینی طور پر اپنے نام کی جگہ کی ضرورت ہوتی ہے۔ یہاں تک کہ ہر ٹیم دیو ماحول اور پروڈ ماحول کے لیے متعدد نام کی جگہوں کا انتخاب کر سکتی ہے۔
آخر میں، بڑی کاروباری کمپنیاں ہیں جن میں ڈویلپرز کا ایک گروپ دوسرے گروپوں کے وجود کے بارے میں بھی نہیں جانتا ہے۔ ایسی کمپنی عام طور پر تیسرے فریق کے ڈویلپرز کی خدمات حاصل کر سکتی ہے جو اچھی طرح سے دستاویزی APIs کے ذریعے اس کے ساتھ تعامل کرتے ہیں۔ اس طرح کے ہر گروپ میں کئی ٹیمیں اور کئی مائیکرو سروسز شامل ہیں۔ اس صورت میں، آپ کو وہ تمام ٹولز استعمال کرنے کی ضرورت ہے جن کے بارے میں میں نے پہلے بات کی تھی۔
پروگرامرز کو دستی طور پر خدمات کو متعین نہیں کرنا چاہئے اور ان نام کی جگہوں تک رسائی نہیں ہونی چاہئے جو ان سے متعلق نہیں ہیں۔ اس مرحلے پر، بلنگ کے عمل اور وسائل کے انتظام کو آسان بنانے کے لیے، ناقص ترتیب شدہ ایپلی کیشنز کے "دھماکے کے رداس" کو کم کرنے کے لیے کئی کلسٹرز رکھنے کا مشورہ دیا جاتا ہے۔
اس طرح، آپ کی تنظیم کی طرف سے نام کی جگہوں کا مناسب استعمال آپ کو 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