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 किंवा इतर सॉकेट रहदारी पुनर्निर्देशित करत नाहीत.

संबंधित लेख