Kubernetes Pod मा प्रोक्सी वातावरण चरहरू सेट गर्नुहोस्

समर्थित HTTP प्रोक्सी चरहरू Kubernetes कन्टेनर विनिर्देशमा राख्नुहोस् र क्लस्टरका प्रत्यक्ष मार्गहरूलाई इमेज-पुल कन्फिगरेसनबाट छुट्टै राख्नुहोस्।

Kubernetes नोडमा चल्ने आदेशले shell प्रोक्सी प्रयोग गर्न सक्छ जबकि त्यही नोडको 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 प्रोक्सी सूचीबाट एक endpoint यी कन्टेनर वातावरण मानहरूका लागि उम्मेदवार हो।

इमेज-पुल एप्लिकेसन चल्नुअघि हुन्छ र नोडको कन्टेनर रनटाइमले गर्छ। Pod env ले त्यो पहिलेको रजिस्ट्री जडान कन्फिगर गर्न सक्दैन।

अन्तमा, HTTP प्रोक्सी चरहरूले तिनीहरू प्रयोग गर्ने क्लाइन्टहरूलाई मात्र प्रभाव पार्छ। तिनीहरूले Pod बाट कुनै पनि मनपरी डेटाबेस, UDP वा अन्य सकेट ट्राफिक पुनर्निर्देशन गर्दैनन्।

सम्बन्धित लेखहरू