VPN صارفین کے لیے Pod IP، ClusterIP یا اندرونی لوڈ بیلنسر
Pod کی جگہ لینے تک Pod IP VPN کے ذریعے روٹ کیا جا سکتا ہے۔ براہ راست Pod رسائی، ClusterIP اور اندرونی بیلنسر کا موازنہ کریں، اور ہر ایک کی لاگت کیا ہے۔
VPC CNI کے ساتھ Pod VPC سے پتہ لے سکتا ہے، اور صحیح روٹ والا VPN صارف براہ راست اس تک پہنچ سکتا ہے۔ اس لیے براہ راست Pod رسائی سب سے آسان انتخاب لگتی ہے، اور Pod کی جگہ لینے تک ایسا ہی ہے۔ صارف جو پتہ یاد رکھتا ہے وہ ایپلیکیشن کا ہونا چاہیے، کسی نقول کا نہیں۔ تینوں داخلوں کا موازنہ آخرکار اس پر آتا ہے کہ پتہ کس شے کی ملکیت ہے اور ورک لوڈ کے منتقل ہونے پر کیا کام کرتا رہنا چاہیے۔
پہلے زندگی کے دورانیے کے مطابق چنیں، پھر اس کے مطابق کہ داخلہ قابلِ رسائی بنانے کے لیے نیٹ ورک کو کیا کرنا ہے۔
تین داخلے، تین زندگی کے دورانیے
Pod IP کی ملکیت Pod کے پاس ہے: یہ اسی کے ساتھ مختص ہوتا ہے اور اس کے خاتمے پر چھوڑ دیا جاتا ہے۔ ClusterIP کی ملکیت Service کے پاس ہے اور یہ مجازی ہے، اس کا مفہوم صرف وہاں ہے جہاں کلسٹر کی سروس روٹنگ موجود ہے۔ اندرونی لوڈ بیلنسر کی ملکیت ایک کلاؤڈ وسیلے کے پاس ہے جسے کلسٹر کا کنٹرولر بیک اینڈ سے پروگرام کرتا ہے۔ ملکیت کے یہ ماڈل پہلے ہی بتا دیتے ہیں کہ آپ کو کون سی ناکامی ملے گی: پرانا پتہ، ناقابلِ رسائی نام، یا پرانا بیک اینڈ مجموعہ۔
چننے سے پہلے موازنہ لکھ لیں۔ مالک اور ناکامی کا نام آ جانے کے بعد انتخاب عموماً خود ہو جاتا ہے۔
| Entry | Owner | Failure when the workload moves |
|---|---|---|
| Pod IP | The Pod | Address changes and saved links break |
| ClusterIP | The Service | Virtual address with no meaning outside cluster routing |
| Internal balancer | Cloud resource plus controller | Backends update, but the DNS view is yours to maintain |
براہ راست Pod رسائی: مفید، عارضی
براہ راست رسائی کنٹرول شدہ جانچ کے لیے واقعی مفید ہے: ایک منتظم، ایک مختصر سیشن، ایک مخصوص پورٹ۔ مگر صارفین کے لیے یہ خراب معاہدہ ہے، کیونکہ پتہ عمل درآمد کی تفصیل ہے جو ہر تعیناتی پر بدلتا ہے۔ اور اسے ویکی میں درج کرنا ہی وہ راستہ ہے جس سے چلتی ہوئی سروس افواہ بن جاتی ہے۔
یہ کشادہ قواعد کو بھی دعوت دیتا ہے۔ ایک منتظم کو ایک Pod تک پہنچنے کی اجازت نوڈ سب نیٹ کے ہر پتے کی اجازت نہیں ہے، اور عموماً دوسرا ہی لکھا جاتا ہے۔
ClusterIP: ڈیزائن کے مطابق کلسٹر تک محدود
ClusterIP اس لیے کام کرتا ہے کہ کلسٹر کا ڈیٹا پلین اس کے لیے کلسٹر کے اندر روٹنگ پروگرام کرتا ہے۔ VPN پر لیپ ٹاپ سے پتہ کوئی معنی نہیں رکھتا، جب تک کوئی اسے جان بوجھ کر ظاہر نہ کرے۔ svc.cluster.local پر ختم ہونے والا نام کلسٹر DNS کا ہے، اس لیے اسے کسی دوسرے حل کنندہ والے کلائنٹ پر نقل کرنے سے روٹنگ خطا کے بجائے ایسا نام ملتا ہے جو موجود نہیں۔
کلسٹر کے اندر کے پکارنے والوں کے لیے، بشمول دیگر ورک لوڈز، ClusterIP درست داخلہ ہی رہتا ہے۔ یہ صرف کلسٹر کے روٹنگ ڈومین سے باہر صارفین کے لیے اشاعت کا طریقہ نہیں ہے۔
اندرونی لوڈ بیلنسر: شائع شدہ راستہ
اندرونی لوڈ بیلنسر آپ کو مستحکم نجی پتہ اور ایسا نام دیتا ہے جس کی طرف آپ کا زون اشارہ کر سکتا ہے، جب کہ کنٹرولر بیک اینڈ مجموعہ تازہ رکھتا ہے، جیسا کہ EKS لوڈ بیلنسنگ گائیڈ بیان کرتی ہے۔ یہی وہ داخلہ ہے جو عام Pod تبدیلی سے بھی گزر جاتا ہے، بغیر کسی کے دستاویز میں ترمیم کے۔ اس کی لاگت ایک کلاؤڈ وسیلہ، کنٹرولر ترتیب اور VPN سے ایک راستہ ہے، اور لوگ انہی حصوں کو کم سمجھتے ہیں۔
وہی کنٹرولر ماڈل استعمال کریں جو کلسٹر واقعی چلاتا ہے۔ ایک انضمام کے لیے لکھی گئی تشریحات دوسرے پر لاگو نہیں ہوتیں۔
ماخذ پتہ کون ہے
سیکیورٹی گروپس وہ ماخذ دیکھتے ہیں جو ان کی حد پر آتا ہے، اور یہ VPN اور لوڈ بیلنسنگ راستے کے مطابق منسلک کلائنٹ یا ترجمہ شدہ پتہ ہو سکتا ہے۔ EC2 پر مبنی نوڈز پر، عام VPC CNI Pod طے شدہ طور پر نوڈ کے ENI گروپس ورثے میں لیتے ہیں، جب کہ معاون ترتیبات Pod کے مخصوص گروپس منسلک کر سکتی ہیں۔ قواعد دستاویزی راستے کے لیے لکھیں، اندازے والے لیپ ٹاپ پتے کے لیے نہیں۔
ایپلیکیشن کے اپنے سامع اور تصدیق کو الگ کنٹرول کے طور پر رکھیں۔ بہاؤ کی اجازت دینے والا نیٹ ورک قاعدہ اجازت کا فیصلہ نہیں ہے اور اسے ایسا نہیں سمجھا جانا چاہیے۔
صارفین کو کیا دینا ہے
صارفین کو پتہ نہیں، سروس کا نام دیں۔ نام نجی زون میں شائع کریں، اسے اندرونی داخلے کی طرف اشارہ کریں، پھر بیک اینڈ Pod بدل کر جانچیں جب کلائنٹ وہی نام کھلا رکھے۔ یہ مشق اس خصوصیت کی جانچ کرتی ہے جو اہم ہے: معمول کی تعیناتی کے بعد بھی اسی ایپلیکیشن تک پہنچنا۔
براہ راست Pod رسائی کو اپنے دائرے والا دستاویزی عملی استثنا رکھیں، صارفین کی ہدایات سے دور۔