Azure узел aks останавливает исходящий трафик c для указания c ip - PullRequest
0 голосов
/ 06 мая 2020

У нас есть приложение, размещенное в кластере azure aks kubernetes. По сути, это веб-приложение, которое использует серверную часть java с контейнером nginx, настроенным как обратный прокси-сервер для прямого HTTP-трафика c. Большая часть трафика c направляется к серверным службам, но мы направляем пару конечных точек обратно в наш локальный экземпляр приложения (используя домен publi c).

Это настройка работала очень хорошо около недели при довольно значительной нагрузке solid трафик c, а затем внезапно прекратила проксирование трафика c на наши локальные ресурсы. Сначала мы думали, что кто-то изменил настройки брандмауэра, но дальнейшее тестирование показало, что проблема была изолирована на одном узле, на котором размещался прокси-сервер nginx.

Мне удалось ввести s sh в узел и попытаться не удалось подключиться к нашему локальному серверу с использованием http-адреса publi c. Однако я могу получить доступ к любому другому сайту на inte rnet, включая сайты, которые мы размещаем на других IP-адресах. Если я перейду sh на другой узел, я смогу без проблем подключиться к нашим локальным сайтам. Кажется, что наш узел блокирует или блокирует доступ к нашему сайту, но мы не можем найти ответственного механизма. Никаких изменений брандмауэра или конфигурации не произошло. В документации по Azure aks указано, что по умолчанию для HTTP-трафика c нет ограничений. Кто-нибудь сталкивался с этой проблемой?

Вот блок из нашей конфигурации nginx, который передает запросы к нашему локальному экземпляру:

    location /civix/content/oic {
        proxy_pass $on_prem_site;
        proxy_set_header Host $server_name;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_intercept_errors on;
    }

1 Ответ

1 голос
/ 07 мая 2020

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

Чтобы получить немедленную обратную связь, попробуйте отключить настройку proxy_intercept_errors в nginx, чтобы узнать, дает ли это дополнительную полезную информацию.

Проверьте, ограничивает ли локальное приложение / блокирует ли IP-адрес, связанный с выходом отказавшего узла. Если у вас нет доступа к локальному приложению, попробуйте переместить прокси-службу ngingx на новый узел (используйте привязку узла для нацеливания на «хороший» узел - https://docs.microsoft.com/en-us/azure/aks/operator-best-practices-advanced-scheduler#control -pod-scheduling-using-node -selectors-and-affinity ).

Traffi c, вероятно, снова начнет работать, что подтвердит теорию, пока вы устраняете проблемы, которые блокируют на стороне вашего локального приложения.

...