Kubernetes نوڈ پر کوئی کمانڈ شیل پراکسی استعمال کر سکتی ہے جبکہ اسی نوڈ پر موجود Pod کا کوئی پراکسی ماحول نہیں ہوتا۔ کنٹینر کا ماحول اس کی امیج اور Pod ترتیب سے متعین ہوتا ہے۔

ان متغیرات کو معاونت فراہم کرنے والی ایپلیکیشن کے لیے، اس کے موجودہ کنٹینر اندراج میں env کی فہرست شامل کریں:

env:
  - name: HTTP_PROXY
    value: http://proxy.example:8080
  - name: HTTPS_PROXY
    value: http://proxy.example:8080
  - name: NO_PROXY
    value: localhost,127.0.0.1,kubernetes.default.svc,.svc,.cluster.local

Deployment میں یہ spec.template.spec.containers میں متعلقہ کنٹینر کے تحت آتا ہے۔ نئے Pods کو یہ ملنے کے لیے ورک لوڈ کو اس کے معمول کے رول آؤٹ کے ذریعے اپ ڈیٹ کریں۔ جب حقیقی کلائنٹ طلب کرے تو چھوٹے حروف والے نام بھی فراہم کریں۔

بائی پاس فہرست ایک ابتدائی مثال ہے، کلسٹر کے ہر راستے کی فہرست نہیں۔ کلسٹر کا اصل DNS لاحقہ اور داخلی منزلیں استعمال کریں۔ سروس IP استعمال کرنے والی ایپلیکیشنز کو ان کے کلائنٹ کی معاونت کردہ نحو میں اصل سروس رینجز درکار ہو سکتے ہیں۔

Init کنٹینرز کی اپنی کنٹینر تفصیلات ہوتی ہیں۔ جب وہ بیرونی ڈاؤن لوڈ کرتے ہیں تو وہاں مطلوبہ ترتیب شامل کریں۔ عوامی HTTP ڈاؤن لوڈز کے لیے، HTTP پراکسی فہرست سے ایک اینڈ پوائنٹ ان کنٹینر ماحول کی قدروں کے لیے امیدوار ہے۔

امیج کھینچنا ایپلیکیشن چلنے سے پہلے ہوتا ہے اور اسے نوڈ کا کنٹینر رن ٹائم انجام دیتا ہے۔ Pod env اس پہلے کے رجسٹری کنکشن کو ترتیب نہیں دے سکتا۔

آخر میں، HTTP پراکسی متغیرات صرف ان کلائنٹس پر اثر انداز ہوتے ہیں جو انہیں استعمال کرتے ہیں۔ وہ Pod سے کوئی بھی من مانی ڈیٹا بیس، UDP یا دیگر ساکٹ ٹریفک ری ڈائریکٹ نہیں کرتے۔

متعلقہ مضامین