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 ପ୍ରକ୍ସି ତାଲିକାରୁ ଏକ ଏଣ୍ଡପଏଣ୍ଟ ଏହି କଣ୍ଟେନର ପରିବେଶ ମୂଲ୍ୟ ପାଇଁ ପ୍ରାର୍ଥୀ।

ଇମେଜ୍-ପୁଲ ଆପ୍ଲିକେସନ ଚାଲିବା ପୂର୍ବରୁ ଘଟେ ଏବଂ ନୋଡର କଣ୍ଟେନର ରନଟାଇମ୍ ଦ୍ୱାରା ସମ୍ପାଦିତ ହୁଏ। Pod env ସେହି ପୂର୍ବ ରେଜିଷ୍ଟ୍ରି ସଂଯୋଗକୁ କନଫିଗର କରିପାରିବ ନାହିଁ।

ପରିଶେଷରେ, HTTP ପ୍ରକ୍ସି ଚରଗୁଡ଼ିକ କେବଳ ସେଗୁଡ଼ିକୁ ବ୍ୟବହାର କରୁଥିବା କ୍ଲାଏଣ୍ଟଗୁଡ଼ିକୁ ପ୍ରଭାବିତ କରେ। ସେଗୁଡ଼ିକ Pod ରୁ ଯେକୌଣସି ଡାଟାବେସ୍, UDP କିମ୍ବା ଅନ୍ୟ ସକେଟ୍ ଟ୍ରାଫିକକୁ ପୁନଃନିର୍ଦ୍ଦେଶିତ କରେ ନାହିଁ।

ସମ୍ପର୍କିତ ପ୍ରବନ୍ଧ