تقسیم شدہ نظاموں کے آپریشن میں ایک اہم نکتہ ناکامی کو سنبھالنا ہے۔ Kubernetes آپ کے سسٹم کی صحت کی نگرانی کرنے والے کنٹرولرز کا استعمال کرتے ہوئے اس میں مدد کرتا ہے اور ایسی خدمات کو دوبارہ شروع کرتا ہے جنہوں نے کام کرنا چھوڑ دیا ہے۔ تاہم، Kubernetes نظام کی مجموعی صحت کو یقینی بنانے کے لیے آپ کی ایپلی کیشنز کو زبردستی روک سکتا ہے۔ اس سیریز میں، ہم دیکھیں گے کہ آپ کس طرح Kubernetes کو اس کے کام کو زیادہ مؤثر طریقے سے کرنے میں مدد کر سکتے ہیں اور ایپلیکیشن ڈاؤن ٹائم کو کم کر سکتے ہیں۔
کنٹینرز سے پہلے، زیادہ تر ایپلیکیشنز ورچوئل یا فزیکل مشینوں پر چلتی تھیں۔ اگر ایپلیکیشن کریش ہو جائے یا منجمد ہو جائے، تو اس کام کو جاری رکھنے اور پروگرام کو دوبارہ لوڈ کرنے میں کافی وقت لگا۔ بدترین صورت حال میں، کسی کو رات کے وقت، انتہائی نامناسب اوقات میں اس مسئلے کو دستی طور پر حل کرنا پڑتا تھا۔ اگر صرف 1-2 کام کرنے والی مشینیں ایک اہم کام انجام دے رہی تھیں، تو اس طرح کی رکاوٹ مکمل طور پر ناقابل قبول تھی۔
لہذا، دستی ریبوٹس کے بجائے، انہوں نے غیر معمولی ختم ہونے کی صورت میں ایپلیکیشن کو خود بخود دوبارہ شروع کرنے کے لیے عمل کی سطح کی نگرانی کا استعمال شروع کیا۔ اگر پروگرام ناکام ہو جاتا ہے، تو نگرانی کا عمل ایگزٹ کوڈ کو پکڑ لیتا ہے اور سرور کو دوبارہ شروع کر دیتا ہے۔ Kubernetes جیسے نظاموں کی آمد کے ساتھ، نظام کی ناکامیوں کے لیے اس قسم کے ردعمل کو صرف بنیادی ڈھانچے میں ضم کر دیا گیا تھا۔
Kubernetes اس بات کو یقینی بنانے کے لیے کہ وسائل صحت مند رہیں جب وہ خود کنٹینرز سے نوڈس تک سفر کرتے ہیں ایک مشاہدہ-فرق-ایکشن ایونٹ لوپ کا استعمال کرتے ہیں۔
اس کا مطلب ہے کہ آپ کو عمل کی نگرانی کو دستی طور پر چلانے کی ضرورت نہیں ہے۔ اگر کوئی وسیلہ صحت کی جانچ میں ناکام ہو جاتا ہے، تو Kubernetes اسے خود بخود متبادل کے ساتھ فراہم کر دے گا۔ تاہم، Kubernetes صرف ناکامیوں کے لیے آپ کی درخواست کی نگرانی کے علاوہ بہت کچھ کرتا ہے۔ یہ ایک سے زیادہ مشینوں پر چلنے، ایپلیکیشن کو اپ ڈیٹ کرنے، یا آپ کی ایپلیکیشن کے ایک سے زیادہ ورژن بیک وقت چلانے کے لیے ایپلیکیشن کی مزید کاپیاں بنا سکتا ہے۔
لہذا، بہت ساری وجوہات ہیں جن کی وجہ سے کبرنیٹس ایک مکمل صحت مند کنٹینر کو ختم کر سکتے ہیں۔ مثال کے طور پر، اگر آپ اپنی تعیناتی کو اپ گریڈ کرتے ہیں، تو Kubernetes نئے شروع کرتے ہوئے آہستہ آہستہ پرانے پوڈز کو روک دے گا۔ اگر آپ نوڈ کو بند کرتے ہیں، تو Kubernetes اس نوڈ پر تمام پوڈز کو چلانا بند کر دے گا۔ آخر میں، اگر نوڈ میں وسائل ختم ہو جاتے ہیں، تو Kubernetes ان وسائل کو خالی کرنے کے لیے تمام پوڈز کو بند کر دے گا۔
لہذا، یہ ضروری ہے کہ آپ کی درخواست اختتامی صارف پر کم سے کم اثر اور کم از کم بحالی کے وقت کے ساتھ ختم ہو۔ اس کا مطلب یہ ہے کہ بند کرنے سے پہلے، اسے وہ تمام ڈیٹا محفوظ کرنا چاہیے جسے محفوظ کرنے کی ضرورت ہے، تمام نیٹ ورک کنکشنز کو بند کرنا، باقی کام کو مکمل کرنا، اور دیگر ضروری کاموں کا انتظام کرنا چاہیے۔
عملی طور پر، اس کا مطلب یہ ہے کہ آپ کی ایپلیکیشن SIGTERM پیغام کو ہینڈل کرنے کے قابل ہونا چاہیے، پروسیس ٹرمینیشن سگنل جو یونکس آپریٹنگ سسٹمز پر کِل یوٹیلیٹی کے لیے ڈیفالٹ سگنل ہے۔ اس پیغام کو موصول ہونے پر، ایپلی کیشن کو بند کر دینا چاہئے.
ایک بار جب Kubernetes ایک پوڈ کو ختم کرنے کا فیصلہ کرتا ہے، تو کئی واقعات رونما ہوتے ہیں۔ آئیے ہر اس قدم کو دیکھتے ہیں جو کبرنیٹس کنٹینر یا پوڈ کو بند کرتے وقت اٹھاتا ہے۔
ہم کہتے ہیں کہ ہم پھلی میں سے ایک کو ختم کرنا چاہتے ہیں۔ اس مقام پر، یہ نئی ٹریفک موصول کرنا بند کر دے گا - پوڈ میں چلنے والے کنٹینرز متاثر نہیں ہوں گے، لیکن تمام نئی ٹریفک بلاک ہو جائے گی۔
آئیے preStop ہک کو دیکھتے ہیں، جو کہ ایک خاص کمانڈ یا HTTP درخواست ہے جو پوڈ میں موجود کنٹینرز کو بھیجی جاتی ہے۔ اگر آپ کی درخواست SIGTERM وصول کرتے وقت صحیح طریقے سے بند نہیں ہوتی ہے، تو آپ صحیح طریقے سے بند کرنے کے لیے preStop استعمال کر سکتے ہیں۔
SIGTERM سگنل ملنے پر زیادہ تر پروگرام خوبصورتی سے باہر نکل جائیں گے، لیکن اگر آپ فریق ثالث کوڈ یا کوئی ایسا سسٹم استعمال کر رہے ہیں جس پر آپ پوری طرح سے کنٹرول نہیں کرتے ہیں، تو پری اسٹاپ ہک ایپلی کیشن کو تبدیل کیے بغیر زبردست شٹ ڈاؤن کرنے کا ایک بہترین طریقہ ہے۔
اس ہک کو انجام دینے کے بعد، Kubernetes پوڈ میں موجود کنٹینرز کو ایک SIGTERM سگنل بھیجے گا، اور انہیں یہ بتائے گا کہ وہ جلد ہی منقطع ہو جائیں گے۔ یہ سگنل موصول ہونے پر، آپ کا کوڈ شٹ ڈاؤن کے عمل میں آگے بڑھ جائے گا۔ اس عمل میں کسی بھی طویل المدتی کنکشن جیسے ڈیٹا بیس کنکشن یا WebSocket سٹریم کو روکنا، موجودہ حالت کو بچانا، وغیرہ شامل ہو سکتے ہیں۔
یہاں تک کہ اگر آپ پری اسٹاپ ہک استعمال کرتے ہیں، تو یہ چیک کرنا بہت ضروری ہے کہ جب آپ SIGTERM سگنل بھیجتے ہیں تو آپ کی ایپلی کیشن کے ساتھ بالکل کیا ہوتا ہے، اور یہ کیسا برتاؤ کرتا ہے، تاکہ پوڈ کے بند ہونے کی وجہ سے ہونے والے واقعات یا سسٹم کے آپریشن میں تبدیلیاں نہ آئیں۔ آپ کے لئے ایک حیرت.
اس مقام پر، Kubernetes مزید کارروائی کرنے سے پہلے، ایک مخصوص وقت کا انتظار کرے گا، جسے ٹرمینیشن گریس پیریڈ سیکنڈ کہا جاتا ہے، یا جب اسے SIGTERM سگنل موصول ہوتا ہے تو اسے خوبصورتی سے بند کرنے کی مدت۔
پہلے سے طے شدہ طور پر یہ مدت 30 سیکنڈ ہے۔ یہ نوٹ کرنا ضروری ہے کہ یہ preStop ہک اور SIGTERM سگنل کے ساتھ متوازی چلتا ہے۔ Kubernetes preStop ہک اور SIGTERM کے ختم ہونے کا انتظار نہیں کرے گا- اگر آپ کی درخواست TerminationGracePeriod ختم ہونے سے پہلے ختم ہو جاتی ہے، تو Kubernetes فوراً اگلے مرحلے پر چلے جائیں گے۔ لہذا، چیک کریں کہ سیکنڈوں میں اس مدت کی قدر پوڈ کو صحیح طریقے سے بند کرنے کے لیے درکار وقت سے کم نہیں ہے، اور اگر یہ 30s سے زیادہ ہے تو YAML میں مدت کو مطلوبہ قدر تک بڑھا دیں۔ دی گئی مثال میں، یہ 60 کی دہائی ہے۔
اور آخر میں، آخری مرحلہ یہ ہے کہ اگر کنٹینرز گریس پیریڈ کے خاتمے کے بعد بھی چل رہے ہیں، تو وہ ایک SIGKILL سگنل بھیجیں گے اور زبردستی حذف کر دیے جائیں گے۔ اس مقام پر، 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