Proxy-Umgebungsvariablen in einem Kubernetes-Pod setzen

Unterstützte HTTP-Proxy-Variablen in die Kubernetes-Containerspezifikation aufnehmen und direkte Cluster-Routen getrennt von der Image-Pull-Konfiguration halten.

Ein Befehl auf dem Kubernetes-Node kann einen Shell-Proxy verwenden, während ein Pod auf diesem Node keine Proxy-Umgebung hat. Die Umgebung des Containers wird durch sein Image und die Pod-Konfiguration bestimmt.

Für eine Anwendung, die diese Variablen unterstützt, fügen Sie dem vorhandenen Container-Eintrag eine env-Liste hinzu:

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 einem Deployment gehört dies unter den betreffenden Container in spec.template.spec.containers. Aktualisieren Sie die Workload über ihr normales Rollout, damit neue Pods sie erhalten. Geben Sie auch Namen in Kleinbuchstaben an, wenn der tatsächliche Client sie verlangt.

Die Bypass-Liste ist eine erste Veranschaulichung, keine Bestandsaufnahme jeder Cluster-Route. Verwenden Sie das echte DNS-Suffix des Clusters und die internen Ziele. Anwendungen, die Service-IPs verwenden, benötigen möglicherweise die tatsächlichen Service-Bereiche in einer Syntax, die ihr Client unterstützt.

Init-Container haben eigene Containerspezifikationen. Fügen Sie dort die vorgesehene Konfiguration hinzu, wenn sie einen externen Download durchführen. Für öffentliche HTTP-Downloads ist ein Endpunkt aus der HTTP-Proxy-Liste ein Kandidat für diese Container-Umgebungswerte.

Image-Pulls erfolgen, bevor die Anwendung läuft, und werden von der Container-Runtime des Nodes ausgeführt. Die Pod-Umgebung kann diese frühere Registry-Verbindung nicht konfigurieren.

Schließlich wirken HTTP-Proxy-Variablen nur auf Clients, die sie verwenden. Sie leiten keinen beliebigen Datenbank-, UDP- oder anderen Socket-Verkehr aus dem Pod um.

Ähnliche Artikel