VPN سائیڈ کار کو شروع کے قاعدے اور ناکامی کے قاعدے کی ضرورت ہے

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

ترتیب صرف پہلی درخواست کو روکتی ہے

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

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

بتائیں گیٹ کیا دیکھتا ہے: ایک عمل موجود ہے، ایک انٹرفیس موجود ہے، ایک handshake مکمل ہوا۔ ان میں سے ہر دعویٰ «اس pod کو درکار منزلوں تک ڈیٹا کا راستہ کام کرتا ہے» سے کمزور ہے۔

ڈیٹا کے راستے کو فرض کرنے کے بجائے نافذ کریں

پروب ایک لمحے کی جانچ ہے اور firewall وہ خصوصیت ہے جو لمحوں کے درمیان لاگو ہوتی ہے۔ اگر تقاضا یہ ہے کہ ایپ کی ٹریفک کبھی ٹنل سے باہر نہ جائے، تو اسے مشترکہ نیٹ ورک نیم اسپیس میں قبول-یا-مسترد قاعدے کے طور پر بیان کرنا ہوگا۔ کنٹینر شروع کرنے کی ترتیب یہ تقاضا نہیں اٹھا سکتی۔ صرف ایک قاعدہ اٹھا سکتا ہے۔

ایک pod کے کنٹینرز وہ نیم اسپیس مشترکہ رکھتے ہیں، اس لیے نفاذ کا نقطہ خود نیم اسپیس ہے۔ آپ جو بھی لکھیں، اسے ٹنل کا اپنا بیرونی رابطہ دستیاب چھوڑنا ہوگا، کیونکہ ایپ کی حفاظت کے لیے اسے بلاک کرنا ایپ کا درکار راستہ کاٹ دیتا ہے۔

ناکامی کی پالیسی واضح طور پر طے کریں: جب ٹنل صحت مند نہ ہو تو ایپ کی ٹریفک مکمل طور پر رکنی چاہیے، یا جاری رہ کر غیر محفوظ کے طور پر نشان زد ہونی چاہیے؟ دونوں ہی مدلل ہیں، اور کوئی بھی مخصوص ترتیب میں کنٹینر شروع کرنے سے حاصل نہیں ہوتا۔

جس ٹریفک کا آپ نے ذکر نہیں کیا اسے آزمائیں

کنٹرول شدہ ٹنل ناکامی کے دوران نئی درخواست لیں اور دیکھیں کہ وہ باہر جاتی ہے یا نہیں۔ پھر ان راستوں کے لیے جانچ دہرائیں جنہیں ایگزٹ ایڈریس ٹیسٹ کبھی نہیں چھوتا: کلسٹر کے اندر DNS حل، IPv6 منزلیں، اور وہ سروسز جن تک عوامی انٹرنیٹ کے بجائے کلسٹر کے اندرونی پتوں سے رسائی ہوتی ہے۔ یہی وہ راستے ہیں جو ٹنل مرنے کے بعد بھی خاموشی سے کام کرتے رہتے ہیں۔

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

جانچ صرف صاف آغاز کے بعد ہی نہیں، سائیڈ کار ری اسٹارٹ کے بعد بھی دہرائیں۔ دوبارہ شروع ہونے والا ٹنل کنٹینر نیم اسپیس کو راستوں اور پالیسی کے ساتھ درمیانی حالت میں چھوڑ سکتا ہے۔

تعیناتی کا ریکارڈ لکھیں

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

حفاظت سمجھی گئی ہیلتھ جانچ سب سے مہنگی قسم کا سبز اشارہ ہے، کیونکہ یہ لوگوں کو سوال پوچھنے سے روک دیتی ہے۔ دستاویزات میں اسے درست نام دینے کی لاگت ایک جملہ ہے اور یہ اسے روکتی ہے۔

آخر میں، ایپ چلتی حالت میں بحالی کے راستے کی ایک بار جانچ کریں۔ ایسا ڈیزائن جو اخراج بحال کرنے کے لیے pod دوبارہ بنانے کا تقاضا کرتا ہے وہ ایک فیصلہ ہے، اور اسے آپ کا کیا ہوا فیصلہ ہونا چاہیے، آپ کی دریافت نہیں۔