Kubernetes میں Pod VPN بمقابلہ ایگریس گیٹ وے: سرنگ کس کی ہے؟
Pod اپنا نیٹ ورک نیم اسپیس رکھتا ہے، اس لیے اصل انتخاب یہ ہے کہ سرنگ کس پرت کے پاس ہے: ہر ورک لوڈ کے لیے شناخت یا ایک مشترکہ ماخذ کے ساتھ CNI کی رہنمائی والا اخراج۔
آپ vpn-gateway نامی Pod تعینات کرتے ہیں، ایک ٹیسٹ کلائنٹ کو اس کے پتے کی طرف بھیجتے ہیں اور پیکٹ غائب ہوتے دیکھتے ہیں۔ مینی فیسٹ میں کچھ بھی غلط نہیں اور kubelet کو کوئی شکایت نہیں۔ وجہ ساختی ہے، کنفیگریشن کی نہیں: Kubernetes ہر Pod کو اس کا اپنا نیٹ ورک نیم اسپیس دیتا ہے، اس لیے نام، لیبل یا مشترکہ API نیم اسپیس اس بات میں کچھ نہیں بدلتے کہ پیکٹ کہاں جاتے ہیں۔ اس لیے VPN ٹریفک کلسٹر سے کیسے نکلے گا یہ طے کرنا ملکیت کے سوال سے شروع ہوتا ہے، کنٹینر امیجز سے نہیں۔
دو طریقے زیادہ تر حقیقی تعیناتیوں کو ڈھانپتے ہیں، اور وہ ایک دوسرے کے بدلے استعمال نہیں ہو سکتے۔ ایک سرنگ کو ورک لوڈ کے اپنے نیٹ ورک نیم اسپیس کے اندر رکھتا ہے۔ دوسرا CNI سے کہتا ہے کہ منتخب ٹریفک کو مقررہ گیٹ وے نوڈ سے گزاردے۔ وہ مختلف طریقوں سے ناکام ہوتے ہیں، مختلف طریقوں سے اسکیل ہوتے ہیں اور مختلف ٹیموں کے ماتحت ہوتے ہیں، اسی لیے کنٹینر کا سوال عام طور پر ایسی بحث پیدا کرتا ہے جو کبھی طے نہیں ہوتی۔
Pod کی حد نیم اسپیس ہے، جمپ ہوسٹ نہیں
Linux نیٹ ورک نیم اسپیس اپنے انٹرفیس، پتوں، راستوں اور فائر وال قواعد کا مالک ہوتا ہے، اور ہر Pod کو ایک ملتا ہے۔ اس Pod کے اندر کے کنٹینر اس میں شامل ہوتے ہیں، اور یہی وجہ ہے کہ ایک معاون کنٹینر ایسے راستے دوبارہ لکھ سکتا ہے جن پر ایپلیکیشن بعد میں چلتی ہے۔ پڑوسی Pod کے پاس دکھنے میں یکساں لیکن مکمل طور پر الگ اسٹیک ہوتا ہے۔ گیٹ وے Pod کے ورثے میں لینے کے قابل کوئی مشترکہ جدول نہیں، اور ایک نیم اسپیس سے دوسرے میں ٹریفک کی کوئی مضمر منتقلی نہیں۔
اسی لیے گیٹ وے-Pod پیٹرن صرف اس وقت کام کرتا ہے جب اوپر سے کوئی چیز واقعی اسے پیکٹ بھیجے: ایک Service، نوڈ پر مستقل راستہ یا CNI میں اسٹیئرنگ پالیسی۔ صرف پتہ کچھ نہیں کھینچتا۔
ہر Pod کے لیے سرنگ کیا دیتی ہے، اور کیا قیمت پڑتی ہے
ورک لوڈ کے نیم اسپیس میں چلنے والی سرنگ اس ورک لوڈ کو اپنی کلائنٹ شناخت دیتی ہے، جسے کئی ریموٹ ایکسیس سروسز سیشن کی اجازت یا حساب سے پہلے مانگتی ہیں۔ نقصان کا دائرہ بھی مقامی رہتا ہے: ٹوٹی سرنگ سب کے استعمال کردہ مشترکہ راستے کے بجائے ایک Deployment بند کر دیتی ہے۔ یہ کیسے چلتی ہے یہ عمل درآمد پر منحصر ہے، اور یہیں لوگ غلط اندازہ لگاتے ہیں۔
جس سیٹ اپ کو صرف کرنل حالت درکار ہو وہ init کنٹینر میں مکمل ہو کر نکل سکتا ہے۔ جس یوزر اسپیس ڈیمون کو Pod کی پوری زندگی زندہ رہنا ہے اسے Kubernetes 1.29 میں مقامی سائیڈ کار کے طور پر متعارف کردہ دوبارہ شروع ہونے والا init کنٹینر فارم درکار ہے، اور یہ فرق ذائقے سے نہیں، سرنگ کے عمل درآمد سے آتا ہے۔ اس ماڈل کی قیمت نقل ہے: ہر ریپلیکا تصدیق کرتا ہے، اپنا سرنگ پتہ پاتا ہے اور ایک ریموٹ سیشن سلاٹ استعمال کرتا ہے، اس لیے آٹو اسکیلنگ واقعہ لنک کے دوسری طرف صلاحیت کا واقعہ بن جاتا ہے۔ ایک اسناد کو تمام ریپلیکاز میں کاپی کرنا وہ قیمت نہیں ہٹاتا، یہ آڈٹ ٹریل ہٹاتا ہے۔ صلاحیتیں بھی اسی جانچ کی حقدار ہیں، کیونکہ اپنے نیم اسپیس میں NET_ADMIN چاہنے والی سرنگ کے پاس privileged: true مثال کے پورے ہوسٹ پر اختیار ورثے میں لینے کی کوئی وجہ نہیں۔
جب CNI کے پاس اخراج ہو
اگر CNI اسے سپورٹ کرتا ہے تو ایگریس گیٹ وے ورک لوڈ اور منزل کی حد کے مطابق ٹریفک منتخب کرتا ہے، پھر اسے ایک قابل اندازہ ماخذ پتے کے تحت منتخب نوڈز سے بھیجتا ہے۔ Cilium کا ورژن عام حوالہ ہے، اور اس کی دستاویزات واضح کہتی ہیں کہ اس خصوصیت کے لیے مخصوص Cilium کنفیگریشن اور درست انٹرفیس و پتوں والے گیٹ وے نوڈز درکار ہیں۔ یہ Pod بننے کے بعد کی ایک ابتدائی مدت بھی بتاتی ہے جب اسٹیئرنگ ابھی نافذ نہیں ہوتی، جو فٹ نوٹ نہیں، ڈیزائن ان پٹ ہے۔
اس تاخیر کو اپنے وعدے کے سامنے پڑھیں۔ اگر قاعدہ یہ ہے کہ کوئی ٹریفک کسی دوسرے راستے سے نہیں نکل سکتا، تو خلا کے دوران بھیجنے والا نیا Pod اسے پہلے ہی توڑ چکا ہے، اس لیے اسٹارٹ اپ ترتیب کو اپنا جواب چاہیے: پالیسی نافذ ہونے تک ایپلیکیشن روکیں، یا وہ ونڈو قبول کریں اور دستاویز کریں۔
دعوے کو تنگ رکھیں۔ ایگریس گیٹ وے راستہ منتخب کرتا ہے اور اس کا ترجمہ کرتا ہے۔ یہ VPN ختم نہیں کرتا، اور پیچھے معاون کنکشن کے بغیر کلسٹر کو آپ کے ریموٹ نیٹ ورک کا کلائنٹ نہیں بناتا۔
| Question | Per-Pod tunnel | CNI egress gateway |
|---|---|---|
| Who holds the client identity | Each workload | The gateway, shared |
| What scaling changes | Enrollment and sessions per replica | Throughput and capacity per node |
| What the remote side sees | Distinct addresses | One translated source |
| Failure scope | One Deployment | Every workload behind the gateway |
ترجمہ خاموشی سے بدل دیتا ہے کہ دور والا فریق کیا دیکھتا ہے
جیسے ہی گیٹ وے ماخذ دوبارہ لکھتا ہے، ہر Pod کے پتے جاتے رہتے ہیں، اس لیے شناخت پر مبنی اجازت فہرست ایک مشترکہ پتے پر مبنی فہرست بن جاتی ہے۔ یہ خامی نہیں، تبادلہ ہے: دیکھ بھال کے کم قواعد، کچھ غلط برتاؤ کرے تو موٹا الزام۔
ایپلیکیشن سطح کی تصدیق اور درخواست لاگنگ کو وہ اٹھانا ہوگا جو نیٹ ورک اب رپورٹ نہیں کرتا۔ گیٹ وے کی صلاحیت اور تبدیلی کو مشترکہ بنیادی ڈھانچہ سمجھیں، کیونکہ ایک نوڈ کا ری بوٹ اب اس کے پیچھے ہر ورک لوڈ میں خلل ڈالتا ہے، اور واپسی کا راستہ جلدی جانچیں: دور والے سرے کو ترجمہ شدہ پتے تک پہنچنے کا طریقہ معلوم ہونا چاہیے، عام طور پر ایسے راستے یا NAT سے جس کا مالک انسان ہو، مینی فیسٹ نہیں۔ پتہ منصوبہ بندی بھی یہیں آتی ہے، کیونکہ اوورلیپ کرنے والی کلسٹر اور ریموٹ حدود دونوں ماڈل توڑتی ہیں اور IPv6 اپنانا متضاد منصوبے کا بہانہ نہیں۔
ملکیت سے فیصلہ کریں، پھر وعدہ کی گئی ناکامی جانچیں
ہر Pod کے لیے سرنگ تب چنیں جب ریموٹ سروس انفرادی ورک لوڈز کی تصدیق کرتی ہے، جب صرف چند Deployment کو لنک درکار ہو، اور جب ناکامی مقامی رہنی چاہیے۔ گیٹ وے تب چنیں جب نیٹ ورک ٹیم کے پاس پہلے ہی راستہ ہو، جب کئی ورک لوڈ ایک منزل مشترکہ رکھیں، اور جب مستقل ماخذ پتہ ہی پوری مشق کا مقصد ہو۔
بہرحال، مستقل حالت نہیں، وہ خصوصیت جانچیں جو آپ نے بیچی۔ ایک Pod بنائیں، اسے فوراً بھیجنے دیں، اور اگر وعدہ تھا کہ سرنگ سے کچھ نہیں بچتا تو پہلے چند سیکنڈ دیکھیں۔ پانچ ریپلیکاز تک اسکیل کریں اور اگر وعدہ ہر ورک لوڈ کے لیے شناخت تھا تو دور والا سرا جن سیشنز کی رپورٹ کرتا ہے انہیں گنیں۔ یہ دو جانچیں مینی فیسٹ کے جائزے سے کہیں تیزی سے طریقہ کار کی حدیں بے نقاب کرتی ہیں، اور بتاتی ہیں کہ اگلا واقعہ کس ٹیم کا ہے۔