Ang isang utos sa node ng Kubernetes ay maaaring gumamit ng shell proxy habang ang isang Pod sa node na iyon ay walang anumang environment ng proxy. Ang environment ng container ay tinutukoy ng image nito at ng konfigurasyon ng Pod.

Para sa isang aplikasyon na sumusuporta sa mga variable na ito, magdagdag ng listahan ng env sa umiiral na entry ng container nito:

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

Sa isang Deployment, ito ay nasa ilalim ng kaugnay na container sa spec.template.spec.containers. I-update ang workload sa pamamagitan ng normal na paglabas nito upang matanggap ito ng mga bagong Pod. Magbigay din ng mga pangalan sa maliit na titik kapag hinihiling ito ng aktwal na kliyente.

Ang listahan ng bypass ay isang panimulang halimbawa, hindi isang imbentaryo ng bawat ruta sa cluster. Gamitin ang aktwal na suffix ng DNS ng cluster at ang mga panloob na destinasyon. Maaaring kailanganin ng mga aplikasyong gumagamit ng IP ng serbisyo ang aktwal na mga saklaw ng serbisyo sa sintaks na sinusuportahan ng kanilang kliyente.

Ang mga init container ay may sariling specipikasyon ng container. Idagdag doon ang inilaan na konfigurasyon kapag nagsasagawa sila ng panlabas na pag-download. Para sa mga pampublikong pag-download ng HTTP, ang isang endpoint mula sa listahan ng HTTP proxy ay isang kandidato para sa mga halagang ito ng environment ng container.

Ang paghila ng image ay nangyayari bago tumakbo ang aplikasyon at ginagawa ito ng runtime ng container ng node. Hindi maaaring i-configure ng environment ng Pod ang naunang koneksyon sa registry na iyon.

Sa wakas, ang mga variable ng proxy ng HTTP ay nakakaapekto lamang sa mga kliyenteng gumagamit ng mga ito. Hindi nila nire-redirect ang anumang arbitraryong trapiko ng database, UDP o iba pang socket mula sa Pod.

Kaugnay na mga artikulo