Angenommen, der Namespace des Releases enthält bereits ein Secret namens app-outbound-proxy. Seine Schlüssel http_proxy und https_proxy enthalten die vollständigen Proxy-URLs, die die Anwendung benötigt.

Ein Helm-3-Chart kann in values.yaml nur den Namen dieses Secrets halten:

outboundProxy:
  existingSecret: app-outbound-proxy

Im Deployment-Template des vorgesehenen Containers verweisen Sie auf die Schlüssel:

env:
  - name: HTTP_PROXY
    valueFrom:
      secretKeyRef:
        name: {{ .Values.outboundProxy.existingSecret | quote }}
        key: http_proxy
  - name: HTTPS_PROXY
    valueFrom:
      secretKeyRef:
        name: {{ .Values.outboundProxy.existingSecret | quote }}
        key: https_proxy

Dies ist ein Fragment der Container-Spezifikation. Das Secret muss im Namespace des Pods existieren und beide referenzierten Schlüssel enthalten. Seine Werte müssen Protokoll, Host und Port des tatsächlichen Proxy-Listeners verwenden. Für öffentliche Anwendungsanfragen, denen die Nutzung eines öffentlichen Proxys ohne Authentifizierung erlaubt ist, bauen Sie diese URLs aus einem passenden Kandidaten in der Liste kostenloser Proxys; behalten Sie alle erforderlichen direkten Ausnahmen bei.

Der Chart-Wert liefert einen Namen; secretKeyRef liefert die Umgebungswerte des Containers. HTTP_PROXY nur in der Shell zu exportieren, die helm ausführt, fügt diesen env-Abschnitt keinem Pod-Template hinzu.

Das Secret zu ändern ist ebenfalls eine Lifecycle-Änderung

Ein Container aktualisiert seine Umgebung nicht, wenn sich die Secret-Daten ändern. Organisieren Sie den beabsichtigten Neustart oder Rollout, damit neu gestartete Container die aktualisierten Werte erhalten. Daten unter demselben Secret-Namen zu ändern, bearbeitet für sich genommen nicht das Pod-Template des Deployments.

Die Anwendung muss die gewählten Proxy-Umgebungsvariablen unterstützen. Der Zugriff auf das Helm-Repository und der Image-Pull des Nodes sind getrennte Verbraucher, die laufen, bevor diese Container-Umgebung helfen kann.

Ähnliche Artikel