O comandă de pe nodul Kubernetes poate folosi un proxy de shell, în timp ce un Pod de pe acel nod nu are niciun mediu proxy. Mediul containerului este definit de imaginea acestuia și de configurația Pod-ului.

Pentru o aplicație care acceptă aceste variabile, adăugați o listă env la intrarea existentă a containerului:

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

Într-un Deployment, aceasta se află sub containerul relevant din spec.template.spec.containers. Actualizați sarcina de lucru prin implementarea sa obișnuită, astfel încât noile Pod-uri să o primească. Furnizați și nume cu litere mici atunci când clientul real le solicită.

Lista de excludere este o ilustrare de început, nu un inventar al fiecărei rute din cluster. Folosiți sufixul DNS real al clusterului și destinațiile interne. Aplicațiile care folosesc IP-uri de serviciu pot avea nevoie de intervalele de serviciu reale într-o sintaxă acceptată de clientul lor.

Containerele init au propriile specificații de container. Adăugați acolo configurația dorită atunci când efectuează o descărcare externă. Pentru descărcări HTTP publice, un punct final din lista de proxy-uri HTTP este un candidat pentru aceste valori de mediu ale containerului.

Descărcarea imaginilor are loc înainte ca aplicația să ruleze și este efectuată de runtime-ul de containere al nodului. Mediul Pod-ului nu poate configura acea conexiune anterioară la registru.

În final, variabilele proxy HTTP afectează doar clienții care le folosesc. Ele nu redirecționează trafic arbitrar de baze de date, UDP sau alte socketuri din Pod.

Articole similare