Pod، نوڈ یا کلسٹر: VPN sidecar دراصل کیا دوبارہ روٹ کرتا ہے

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

مشترک namespace، مشترک نتائج

ایک Pod میں دو کنٹینر loopback پر بات کرتے ہیں اور وہی انٹرفیس دیکھتے ہیں، اور اسی لیے sidecar کا نمونہ کام کرتا ہے: ایپلیکیشن کو یہ جاننے کی ضرورت نہیں کہ کوئی ٹنل ہے، کیونکہ جو روٹ وہ حل کرتی ہے وہ اسی namespace میں نصب ہوا تھا جو وہ استعمال کرتی ہے۔ یہی خصوصیت بتاتی ہے کہ sidecar کی غلطیاں ایپلیکیشن کی غلطیاں ہیں۔ جو روٹ بہت زیادہ پکڑ لے، یا جو DNS تبدیلی ٹنل کے اندر کے ریزالور کی طرف اشارہ کرے، وہ اس Pod کے ہر عمل پر فوراً لاگو ہوتی ہے۔ مشترک namespace میں کنٹینر کے حساب سے روٹنگ نہیں ہوتی، اس لیے sidecar کو ایک عمل تک محدود نہیں کیا جا سکتا۔

جائزے کے وقت یہی طریقہ کار یاد رکھنا چاہیے: اثر کا دائرہ Pod ہے، نہ نوڈ اور نہ کلسٹر۔

sidecar کہاں نہیں پہنچتا

دوسرے Pod اپنے namespace اور اپنی روٹنگ رکھتے ہیں، اس لیے جس ورک لوڈ کو وہی ایگریس چاہیے اسے وہی sidecar یا اس کے بجائے نوڈ سطح کا ڈیزائن چاہیے۔ نوڈ کی ٹریفک بھی Pod namespace سے باہر ہے، اور ہوسٹ نیٹ ورک والے Pod جان بوجھ کر اس علیحدگی سے مکمل طور پر باہر نکل جاتے ہیں۔ اگر آپ کچھ آسان تک پہنچنے کے لیے sidecar کو ہوسٹ نیٹ ورکنگ کے ساتھ چلاتے ہیں تو آپ نے دائرہ ایک Pod سے پورے نوڈ تک بڑھا دیا ہے اور یہ بلند آواز میں کہنا چاہیے۔

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

روٹ منصوبہ: Pod، سروس، نوڈ اور VPN کی رینجز

چاروں رینجز لکھیں اور کچھ بھی تعینات کرنے سے پہلے اوورلیپ جانچیں: Pod CIDR، سروس CIDR، نوڈ کے پتے اور VPN کے پیچھے کی منزلیں۔ VPN کی نجی رینجز اور کلسٹر کی اپنی جگہ کے درمیان اوورلیپ نایاب نہیں، اور ڈیفالٹ روٹ اس کے لیے غلط حل ہے۔ روٹ منصوبہ اسی ریپوزٹری میں ہونا چاہیے جس میں مینی فیسٹ ہے، کیونکہ اگلا کلسٹر بالکل مختلف Pod اور سروس رینجز دے سکتا ہے۔

DNS منصوبے کا حصہ ہے، الگ فکر نہیں۔ ریزالور کنفیگریشن دوبارہ لکھنے والا sidecar کلسٹر کے اندر سروس کی دریافت توڑ سکتا ہے، جبکہ بیرونی تلاش بالکل ٹھیک چلتی رہتی ہے۔

آغاز اور ناکامی واضح حالتیں ہیں

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

یہ خلا صحت مند کلسٹر میں مختصر اور ٹوٹے کلسٹر میں مستقل ہوتا ہے، اور حملہ آور یا حادثاتی ڈیٹا لیک اسی خصوصیت کو پسند کرتے ہیں۔

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

صلاحیتیں، پالیسیاں اور ایپ کنٹینر سے جانچ

انٹرفیس بنانے اور روٹ بدلنے کے لیے درکار صلاحیتیں دینا استحقاق کا فیصلہ ہے، اور الگ تھلگ Pod کے لیے موزوں استحقاق نوڈ اسٹیک پر خود بخود موزوں نہیں ہوتا۔ کلسٹر کی معاونت کردہ نیٹ ورک اور سکیورٹی پالیسی کے طریقے استعمال کریں، اور یہ نہ سمجھیں کہ ہر CNI یا پالیسی نفاذ VPN انٹرفیس کے ساتھ یکساں سلوک کرتا ہے؛ فرق انہی ناکامی کے واقعات میں نظر آتا ہے جو آپ کے لیے اہم ہیں۔

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

VPN کنفیگریشن کے ساتھ کلسٹر کے نیٹ ورک مفروضوں کی دستاویز بنائیں۔ پھر ورک لوڈ کو دوسرے کلسٹر میں منتقل کرنا خاموشی سے کام بند کرنے والی امیج تبدیلی کے بجائے روٹ منصوبہ جانچنے کی مشق ہوتا ہے۔