Komando sur la Kubernetes-nodo povas uzi ŝelan prokurilon dum Pod sur tiu nodo havas neniun prokuran medion. La medio de la ujo estas difinita de ĝia bildo kaj Pod-agordo.

Por aplikaĵo subtenanta ĉi tiujn variablojn, aldonu env-liston al ĝia ekzistanta uja ero:

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

En Deployment, ĉi tio apartenas sub la koncerna ujo en spec.template.spec.containers. Ĝisdatigu la laborŝarĝon per ĝia normala disvolvo por ke novaj Pods ricevu ĝin. Provizu ankaŭ nomojn per minuskloj kiam la reala kliento postulas ilin.

La preterpasa listo estas komenca ilustraĵo, ne inventaro de ĉiu klustera vojo. Uzu la realan DNS-sufikson de la klustero kaj internajn celojn. Aplikaĵoj uzantaj servajn IP-adresojn eble bezonos la realajn servajn gamojn en sintakso subtenata de ilia kliento.

Init-ujoj havas proprajn ujajn specifojn. Aldonu la celatan agordon tie kiam ili faras eksteran elŝuton. Por publikaj HTTP-elŝutoj, finpunkto el la HTTP-prokura listo estas kandidato por ĉi tiuj ujaj medivaloroj.

Bild-elŝutoj okazas antaŭ ol la aplikaĵo funkcias kaj plenumas ilin la uja runtimo de la nodo. Pod-medio ne povas agordi tiun pli fruan registran konekton.

Fine, HTTP-prokuraj variabloj efikas nur al klientoj, kiuj uzas ilin. Ili ne alidirektas arbitran datumbazan, UDP aŭ alian ingan trafikon de la Pod.

Rilataj artikoloj