Использование существующего Secret для переменных прокси в чарте Helm

Ссылайтесь на полные URL прокси из Secret в шаблоне Deployment Helm 3, а не предполагайте, что переменная оболочки станет окружением контейнера.

Предположим, в пространстве имён релиза уже есть Secret с именем app-outbound-proxy. Его ключи http_proxy и https_proxy содержат полные URL прокси, необходимые приложению.

Чарт Helm 3 может хранить в values.yaml только имя этого Secret:

outboundProxy:
  existingSecret: app-outbound-proxy

В шаблоне Deployment нужного контейнера сослайтесь на ключи:

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

Это фрагмент спецификации контейнера. Secret должен существовать в пространстве имён Pod и содержать оба указанных ключа. Его значения должны использовать протокол, хост и порт реального слушателя прокси. Для публичных запросов приложения, которым разрешено использовать публичный прокси без аутентификации, стройте эти URL из подходящего кандидата в списке бесплатных прокси; сохраняйте все необходимые прямые исключения.

Значение чарта задаёт имя; secretKeyRef задаёт значения окружения контейнера. Простой экспорт HTTP_PROXY в оболочке, где запускается helm, не добавляет этот раздел env в шаблон Pod.

Изменение Secret — тоже изменение жизненного цикла

Контейнер не обновляет своё окружение при изменении данных Secret. Организуйте намеченный перезапуск или rollout, чтобы новые контейнеры получили обновлённые значения. Изменение данных под тем же именем Secret само по себе не правит шаблон Pod в Deployment.

Приложение должно поддерживать выбранные переменные окружения прокси. Доступ к репозиторию Helm и загрузка образа на узле — отдельные потребители, работающие раньше, чем это окружение контейнера сможет помочь.

Похожие статьи