Een commando op het Kubernetes-knooppunt kan een shell-proxy gebruiken, terwijl een Pod op dat knooppunt geen proxy-omgeving heeft. De omgeving van de container wordt bepaald door de image en de Pod-configuratie.

Voor een toepassing die deze variabelen ondersteunt, voegt u een env-lijst toe aan de bestaande containervermelding:

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

In een Deployment hoort dit onder de betreffende container in spec.template.spec.containers. Werk de workload bij via de normale uitrol, zodat nieuwe Pods het ontvangen. Geef ook namen met kleine letters op wanneer de werkelijke client die vereist.

De bypass-lijst is een beginillustratie, geen inventaris van elke route in het cluster. Gebruik het werkelijke DNS-suffix van het cluster en de interne bestemmingen. Toepassingen die service-IP's gebruiken, hebben mogelijk de werkelijke servicebereiken nodig in een syntaxis die hun client ondersteunt.

Init-containers hebben hun eigen containerspecificaties. Voeg daar de bedoelde configuratie toe wanneer ze een externe download uitvoeren. Voor openbare HTTP-downloads is een eindpunt uit de HTTP-proxylijst een kandidaat voor deze container-omgevingswaarden.

Het ophalen van images gebeurt voordat de toepassing draait en wordt uitgevoerd door de container-runtime van het knooppunt. De Pod-omgeving kan die eerdere registerverbinding niet configureren.

Ten slotte beïnvloeden HTTP-proxyvariabelen alleen clients die ze gebruiken. Ze leiden geen willekeurig database-, UDP- of ander socketverkeer van de Pod om.

Gerelateerde artikelen