تقسیم شدہ نظاموں کا نظم کرنا مشکل ہو سکتا ہے کیونکہ ان میں بہت سے متحرک، بدلتے ہوئے عناصر ہوتے ہیں جنہیں سسٹم کے کام کرنے کے لیے مناسب طریقے سے کام کرنے کی ضرورت ہوتی ہے۔ اگر عناصر میں سے کوئی ایک ناکام ہوجاتا ہے، تو سسٹم کو اس کا پتہ لگانا چاہیے، اسے نظرانداز کرنا چاہیے اور اسے ٹھیک کرنا چاہیے، اور یہ سب خود بخود ہونا چاہیے۔ اس Kubernetes بہترین طرز عمل کی سیریز میں، ہم یہ سیکھیں گے کہ کس طرح ایک Kubernetes کلسٹر کی صحت کو جانچنے کے لیے تیاری اور زندہ دلی کے ٹیسٹ مرتب کیے جائیں۔
ہیلتھ چیک سسٹم کو یہ بتانے کا ایک آسان طریقہ ہے کہ آیا آپ کی درخواست کی مثال چل رہی ہے یا نہیں۔ اگر آپ کی درخواست کی مثال نیچے ہے، تو دوسری سروسز کو اس تک رسائی نہیں کرنی چاہیے اور نہ ہی اسے درخواستیں بھیجنی چاہیے۔ اس کے بجائے، درخواست کو ایپلیکیشن کی کسی دوسری مثال پر بھیجا جانا چاہیے جو پہلے سے چل رہا ہے یا بعد میں لانچ کیا جائے گا۔ اس کے علاوہ، سسٹم کو آپ کی درخواست کی کھوئی ہوئی فعالیت کو بحال کرنا چاہیے۔
پہلے سے طے شدہ طور پر، جب پوڈ کے اندر موجود تمام کنٹینرز چل رہے ہوں گے تو Kubernetes ایک پوڈ پر ٹریفک بھیجنا شروع کر دے گا، اور کنٹینرز کے کریش ہونے پر ریبوٹ کر دیں گے۔ یہ پہلے سے طے شدہ نظام کا رویہ شروع کرنے کے لیے کافی اچھا ہو سکتا ہے، لیکن آپ حسب ضرورت سنٹی چیکس کا استعمال کر کے اپنے پروڈکٹ کی تعیناتی کی وشوسنییتا کو بہتر بنا سکتے ہیں۔
خوش قسمتی سے، Kubernetes اسے کرنا کافی آسان بنا دیتا ہے، لہذا ان چیکوں کو نظر انداز کرنے کا کوئی عذر نہیں ہے۔ Kubernetes دو قسم کے ہیلتھ چیک فراہم کرتا ہے، اور ہر ایک کے استعمال کے طریقہ کار میں فرق کو سمجھنا ضروری ہے۔
ریڈی نیس ٹیسٹ کوبرنیٹس کو بتانے کے لیے ڈیزائن کیا گیا ہے کہ آپ کی درخواست ٹریفک کو سنبھالنے کے لیے تیار ہے۔ کسی سروس کو پوڈ پر ٹریفک بھیجنے کی اجازت دینے سے پہلے، Kubernetes کو اس بات کی تصدیق کرنی چاہیے کہ تیاری کی جانچ کامیاب ہے۔ اگر ریڈینس ٹیسٹ ناکام ہو جاتا ہے تو، Kubernetes ٹیسٹ پاس ہونے تک پوڈ پر ٹریفک بھیجنا بند کر دے گا۔
Liveness ٹیسٹ Kubernetes کو بتاتا ہے کہ آیا آپ کی درخواست زندہ ہے یا مردہ۔ پہلی صورت میں، Kubernetes اسے تنہا چھوڑ دے گا، دوسری صورت میں یہ مردہ پوڈ کو حذف کر دے گا اور اس کی جگہ ایک نیا لے آئے گا۔
آئیے ایک ایسے منظر نامے کا تصور کریں جہاں آپ کی ایپلیکیشن کو گرم ہونے اور لانچ کرنے میں 1 منٹ لگتا ہے۔ آپ کی سروس اس وقت تک کام کرنا شروع نہیں کرے گی جب تک کہ ایپلیکیشن مکمل طور پر لوڈ اور چل نہ جائے، حالانکہ ورک فلو پہلے ہی شروع ہو چکا ہے۔ اگر آپ اس تعیناتی کو متعدد کاپیوں تک بڑھانا چاہتے ہیں تو آپ کو بھی پریشانی کا سامنا کرنا پڑے گا، کیونکہ ان کاپیوں کو اس وقت تک ٹریفک موصول نہیں ہونا چاہیے جب تک کہ وہ مکمل طور پر تیار نہ ہوں۔ تاہم، بطور ڈیفالٹ، کنٹینر کے اندر کارروائی شروع ہوتے ہی Kubernetes ٹریفک بھیجنا شروع کر دے گا۔
ریڈینس ٹیسٹ کا استعمال کرتے وقت، Kubernetes سروس کو نئی کاپی پر ٹریفک بھیجنے کی اجازت دینے سے پہلے ایپلیکیشن کے مکمل طور پر چلنے تک انتظار کرے گا۔
آئیے ایک اور منظر نامے کا تصور کرتے ہیں جس میں ایپلی کیشن طویل عرصے تک لٹکتی رہتی ہے، سروسنگ کی درخواستوں کو روکتی ہے۔ جیسا کہ یہ عمل جاری رہتا ہے، بطور ڈیفالٹ Kubernetes فرض کر لے گا کہ سب کچھ ٹھیک ہے اور نان ورکنگ پوڈ کو درخواستیں بھیجنا جاری رکھیں گے۔ لیکن Liveness کا استعمال کرتے وقت، Kubernetes کو پتہ چل جائے گا کہ ایپلیکیشن مزید درخواستیں پیش نہیں کر رہی ہے اور ڈیفالٹ کے طور پر ڈیڈ پوڈ کو دوبارہ شروع کر دے گی۔
آئیے دیکھتے ہیں کہ تیاری اور عملداری کی جانچ کیسے کی جاتی ہے۔ جانچ کے تین طریقے ہیں - HTTP، کمانڈ اور TCP۔ آپ ان میں سے کسی کو بھی چیک کرنے کے لیے استعمال کر سکتے ہیں۔ صارف کو جانچنے کا سب سے عام طریقہ HTTP تحقیقات ہے۔
یہاں تک کہ اگر آپ کی ایپلیکیشن HTTP سرور نہیں ہے، تب بھی آپ Liveness ٹیسٹ کے ساتھ تعامل کرنے کے لیے اپنی ایپلیکیشن کے اندر ہلکا پھلکا HTTP سرور بنا سکتے ہیں۔ اس کے بعد، Kubernetes پوڈ کو پنگ کرنا شروع کر دے گا، اور اگر HTTP کا جواب 200 یا 300 ms کی حد میں ہے، تو یہ اشارہ کرے گا کہ پھلی صحت مند ہے۔ بصورت دیگر، ماڈیول کو "غیر صحت مند" کے طور پر نشان زد کیا جائے گا۔
کمانڈ ٹیسٹ کے لیے، Kubernetes آپ کے کنٹینر کے اندر کمانڈ چلاتا ہے۔ اگر کمانڈ صفر ایگزٹ کوڈ کے ساتھ واپس آتی ہے، تو کنٹینر کو صحت مند کے طور پر نشان زد کیا جائے گا، بصورت دیگر، 1 سے 255 تک ایگزٹ اسٹیٹس نمبر موصول ہونے پر، کنٹینر کو "بیمار" کے طور پر نشان زد کیا جائے گا۔ یہ جانچ کا طریقہ کارآمد ہے اگر آپ HTTP سرور نہیں چلا سکتے یا نہیں چلانا چاہتے، لیکن ایسی کمانڈ چلانے کے قابل ہیں جو آپ کی درخواست کی صحت کو جانچے گا۔
حتمی تصدیقی طریقہ کار TCP ٹیسٹ ہے۔ Kubernetes مخصوص پورٹ پر TCP کنکشن قائم کرنے کی کوشش کرے گا۔ اگر یہ کیا جا سکتا ہے تو، کنٹینر صحت مند سمجھا جاتا ہے؛ اگر نہیں، تو اسے ناقابل عمل سمجھا جاتا ہے. یہ طریقہ کارآمد ثابت ہو سکتا ہے اگر آپ کسی ایسے منظر نامے کو استعمال کر رہے ہیں جہاں HTTP درخواست یا کمانڈ پر عمل درآمد کے ساتھ جانچ بہت اچھی طرح سے کام نہیں کرتی ہے۔ مثال کے طور پر، TCP کا استعمال کرتے ہوئے تصدیق کے لیے اہم خدمات gRPC یا FTP ہوں گی۔
ٹیسٹ کو مختلف پیرامیٹرز کے ساتھ کئی طریقوں سے ترتیب دیا جا سکتا ہے۔ آپ یہ بتا سکتے ہیں کہ انہیں کتنی بار عمل میں لایا جانا چاہیے، کامیابی اور ناکامی کی حدیں کیا ہیں، اور جوابات کے لیے کتنا انتظار کرنا ہے۔ مزید معلومات کے لیے، تیاری اور زندہ دلی کے ٹیسٹ کے لیے دستاویزات دیکھیں۔ تاہم، Liveness ٹیسٹ کو ترتیب دینے میں ایک بہت اہم نکتہ ہے - ٹیسٹنگ میں تاخیر کی ابتدائی ترتیب initialDelaySeconds۔ جیسا کہ میں نے بتایا، اس ٹیسٹ میں ناکامی کے نتیجے میں ماڈیول دوبارہ شروع ہو جائے گا۔ لہذا آپ کو یہ یقینی بنانا ہوگا کہ جب تک ایپلیکیشن تیار نہ ہو جانچ شروع نہ ہو، بصورت دیگر یہ دوبارہ شروع ہونے سے سائیکل چلانا شروع کر دے گی۔ میں بفر سے P99 اسٹارٹ اپ ٹائم یا اوسط ایپلیکیشن اسٹارٹ اپ ٹائم استعمال کرنے کی تجویز کرتا ہوں۔ اس قدر کو ایڈجسٹ کرنا یاد رکھیں کیونکہ آپ کی ایپلیکیشن کے آغاز کا وقت تیز یا سست ہو جاتا ہے۔
زیادہ تر ماہرین اس بات کی تصدیق کریں گے کہ ہیلتھ چیک کسی بھی تقسیم شدہ نظام کے لیے ایک لازمی چیک ہے، اور 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