Налаштування змінних середовища проксі в Pod Kubernetes

Розмістіть підтримувані змінні HTTP-проксі у специфікації контейнера Kubernetes і тримайте прямі маршрути кластера окремо від конфігурації завантаження образів.

Команда на вузлі Kubernetes може використовувати проксі оболонки, тоді як Pod на цьому вузлі не має середовища проксі. Середовище контейнера визначається його образом і конфігурацією Pod.

Для застосунку, що підтримує ці змінні, додайте список env до наявного запису контейнера:

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

У Deployment це розміщується під відповідним контейнером у spec.template.spec.containers. Оновіть робоче навантаження через його звичайне розгортання, щоб нові Pods отримали це. Надайте також імена малими літерами, якщо цього потребує фактичний клієнт.

Список обходу — це початковий приклад, а не перелік кожного маршруту кластера. Використовуйте реальний суфікс DNS кластера та внутрішні призначення. Застосункам, що використовують IP-адреси сервісів, можуть знадобитися фактичні діапазони сервісів у синтаксисі, який підтримує їхній клієнт.

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

Завантаження образів відбувається до запуску застосунку й виконується середовищем виконання контейнерів вузла. Середовище Pod не може налаштувати це попереднє з'єднання з реєстром.

Нарешті, змінні HTTP-проксі впливають лише на клієнтів, які їх використовують. Вони не перенаправляють довільний трафік баз даних, UDP або інших сокетів із Pod.

Схожі статті