Використання наявного 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 дає значення середовища контейнера. Просто export HTTP_PROXY в оболонці, яка запускає helm, не додає цього розділу env до шаблону Pod.

Зміна Secret — це також зміна життєвого циклу

Контейнер не оновлює своє середовище, коли змінюються дані Secret. Організуйте передбачений перезапуск або rollout, щоб щойно запущені контейнери отримали оновлені значення. Зміна даних під тим самим іменем Secret сама по собі не редагує шаблон Pod у Deployment.

Застосунок має підтримувати вибрані змінні середовища проксі. Доступ до сховища Helm і завантаження образу на вузлі — окремі споживачі, які працюють раніше, ніж це середовище контейнера зможе допомогти.

Схожі статті