In opdracht op 'e Kubernetes-node kin in shell-proxy brûke wylst in Pod op dy node gjin proxy-omjouwing hat. De omjouwing fan 'e kontener wurdt bepaald troch syn image en Pod-konfiguraasje.

Foar in applikaasje dy't dizze fariabelen stipet, foegje in env-list ta oan syn besteande kontener-ynfier:

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

Yn in Deployment heart dit ûnder de oanbelangjende kontener yn spec.template.spec.containers. Wurkje de wurklast by fia syn normale rollout sadat nije Pods it krije. Jou ek nammen mei lytse letters as de echte klient dy freget.

De omseil-list is in begjin-útlizzen, gjin ynventaris fan elke klusterrûte. Brûk it echte DNS-suffiks fan it kluster en ynterne bestimmingen. Applikaasjes dy't tsjinst-IP's brûke, hawwe miskien de echte tsjinstberikken nedich yn in syntaksis dy't har klient stipet.

Init-konteners hawwe har eigen kontener-spesifikaasjes. Foegje dêr de bedoelde konfiguraasje ta as se in eksterne download dogge. Foar iepenbiere HTTP-downloads is in einpunt út 'e HTTP-proxy-list in kandidaat foar dizze kontener-omjouwingswearden.

Image-pulls barre foardat de applikaasje rint en wurde útfierd troch de kontener-runtime fan 'e node. Pod-omjouwing kin dy eardere registry-ferbining net konfigurearje.

Ta beslút beynfloedzje HTTP-proxyfariabelen allinnich klanten dy't se brûke. Se stjoere gjin willekeurich databank-, UDP- of oar socketferkear fan 'e Pod om.

Relatearre artikelen