Команда на възела на Kubernetes може да използва прокси в shell, докато 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 прокси е кандидат за тези стойности на средата на контейнера.

Изтеглянето на изображения се извършва преди стартирането на приложението и се изпълнява от runtime за контейнери на възела. Средата на Pod не може да конфигурира тази по-ранна връзка с регистъра.

И накрая, променливите за HTTP прокси влияят само на клиентите, които ги използват. Те не пренасочват произволен трафик към бази данни, UDP или други сокети от Pod.

Подобни статии