Kubernetes Pod में प्रॉक्सी पर्यावरण चर सेट करें

समर्थित HTTP प्रॉक्सी चर को Kubernetes कंटेनर विनिर्देश में रखें और सीधे क्लस्टर मार्गों को इमेज-पुल कॉन्फ़िगरेशन से अलग रखें।

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 या अन्य सॉकेट ट्रैफ़िक को पुनर्निर्देशित नहीं करते।

संबंधित लेख