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 અથવા અન્ય સોકેટ ટ્રાફિકને રીડાયરેક્ટ કરતા નથી.

સંબંધિત લેખો