Proxy-Ëmweltvariabelen an engem Kubernetes Pod setzen

Set ënnerstëtzten HTTP-Proxy-Variabelen an d'Kubernetes-Container-Spezifikatioun a haalt direkt Cluster-Routen getrennt vun der Image-Pull-Konfiguratioun.

En Befehl op dem Kubernetes-Node kann e Shell-Proxy benotzen, während e Pod op deem Node keng Proxy-Ëmwelt huet. D'Ëmwelt vum Container gëtt duerch säin Image an d'Pod-Konfiguratioun definéiert.

Fir eng Applikatioun, déi dës Variabelen ënnerstëtzt, füügt eng env-Lëscht zu hirem existéierende Container-Andro ag:

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

An engem Deployment gehéiert dëst ënner de betraffene Container an spec.template.spec.containers. Aktualiséiert d'Workload duerch hiren normale Rollout, sou datt nei Pods et kréien. Gitt och Nimm a Klengbuchstaben un, wann den tatsächleche Client se verlaangt.

D'Bypass-Lëscht ass eng Ufanks-Illustratioun, net en Inventar vun all Route vum Cluster. Benotzt de richtege DNS-Suffix vum Cluster an déi intern Destinatiounen. Applikatiounen, déi Service-IPen benotzen, brauchen eventuell déi tatsächlech Service-Bereicher an enger Syntax, déi hire Client ënnerstëtzt.

Init-Containeren hunn hir eegen Container-Spezifikatiounen. Füügt déi virgesinn Konfiguratioun do bäi, wann se en externen Download maachen. Fir ëffentlech HTTP-Downloads ass en Endpunkt aus der HTTP-Proxy-Lëscht e Kandidat fir dës Container-Ëmweltwäerter.

Image-Pulls geschéien, ier d'Applikatioun leeft, a ginn vun der Container-Runtime vum Node ausgefouert. Pod-Ëmwelt kann déi fréier Registry-Verbindung net konfiguréieren.

Schlussendlech beaflossen HTTP-Proxy-Variabelen nëmmen d'Clienten, déi se benotzen. Si leeden net arbiträren Datebank-, UDP- oder anere Socket-Trafic aus dem Pod ëm.

Ähnlech Artikelen