Какой «тайм-аут» Azure Kubernetes (AKS) приводит к отключению подключений к входу / выходу модуля Pod в моем кластере? - PullRequest
Новая
       21

Какой «тайм-аут» Azure Kubernetes (AKS) приводит к отключению подключений к входу / выходу модуля Pod в моем кластере?

0 голосов
/ 05 июня 2018

У меня есть работающий кластер со службами, которые все отвечают за установленным рулем Ingress nGinx, работающим на Azure AKS. В итоге это зависело от Azure.

Мой вопрос: почему мое соединение со службами / модулями в этом кластере периодически прерывается (по-видимому,некоторый тайм-аут простоя), и почему такое прерывание соединения, по-видимому, также совпадает с разрывом соединения с моим пользовательским интерфейсом Az AKS Browse?

Это попытка получить окончательный ответ о том, что именно вызываеттайм-аут, из-за которого локальный пользовательский интерфейс прокси «Обзор» отключается от моего кластера (дополнительные сведения о том, почему я прошу следовать).

При работе с Azure AKS из интерфейса командной строки Az вы можете запустить локальный ОбзорПользовательский интерфейс из терминала, используя:

az aks browse --resource-group <resource-group> --name <cluster-name>

Это работает нормально и открывает окно браузера, которое выглядит примерно так (yay):

Azure AKS Disconnects Connections entering pods

В вашем терминале вы увидите что-то вроде:

  1. Прокси-сервер работает на http://127.0.0.1:8001/ Нажмите CTRL + C, чтобы закрыть туннель..
  2. Пересылка из127.0.0.1:8001 -> 9090 Переадресация с
  3. [:: 1]: 8001 -> 9090 Обработка соединения для 8001 Обработка соединения для 8001 Обработка соединения для 8001

Если вы уйдетеподключение к вашему кластеру простаивает в течение нескольких минут (т.е.вы не взаимодействуете с пользовательским интерфейсом) вы должны увидеть следующую распечатку, чтобы указать, что время соединения истекло:

E0605 13: 39: 51.940659 5704 portforward.go: 178] потеряно соединение с модулем

Одна вещь, которую я до сих пор не понимаю, - может ли ДРУГАЯ деятельность внутри Кластера продлить этот тайм-аут, но независимо от того, увидели ли вы вышеизложенное, вы, по сути, в том же месте, что и я ...мы можем говорить о том факте, что все мои другие соединения OUT из модулей на этом сервере также были закрыты каким-либо процессом тайм-аута, который отвечает за разрыв связей с пользовательским интерфейсом AKS.

Так в чем же проблема??

Причина, по которой это проблема для меня, заключается в том, что у меня есть Служба, на которой запущен модуль Ghost Blog, который подключается к удаленной базе данных MySQL с помощью пакета npm под названием «Knex».Как это случается, в более новых версиях Knex есть ошибка (которая еще не устранена), из-за которой, если соединение между клиентом Knex и удаленным сервером БД разрывается и его необходимо восстановить - оно не повторно подключается и просто бесконечнозагружает.

Ошибка nGinx 503 Тайм-аут шлюза

В моей ситуации, когда nGinx Ingress выдал ошибку Тайм-аут 503 шлюза.Это произошло из-за того, что Ghost не отвечал после того, как Idle timeout прервал соединение Knex - поскольку Knex не работал должным образом и не восстанавливает разорванное соединение с сервером должным образом.

Fine. Я откатил Knex, и все отлично работает.

Но почему, черт возьми, мои соединения со стручками изначально отключаются от базы данных?

Следовательно, этот вопрос, мы надеемся, сэкономит несколько будущих человеко-дней попыток устранения проблем с фантомами, которые связаны с Kubernetes (может быть, специфичным для Azure, может быть, нет), обрезая соединения после того, как служба / модуль простаивал для некоторыхвремя.

1 Ответ

0 голосов
/ 20 июля 2018

Краткий ответ:

Azure AKS автоматически развертывает балансировщик нагрузки Azure (с общедоступным IP-адресом) при добавлении нового входа (nGinx / Traefik ... ANY Ingress) - этот балансировщик нагрузки имеетего настройки настроены как «базовый» Azure LB, который имеет 4-минутный тайм-аут соединения.

Этот тайм-аут не только стандартный, но и обязательный (хотя вы МОЖЕТЕ его изменить, см. здесь: https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-tcp-idle-timeout). При этом невозможно отменить его полностью для любого трафика, который направляется извне с IP-адреса балансировщика нагрузки - наибольшая поддерживаемая в настоящее время продолжительность составляет 30 минут.

Существуетнет родного Azure способа обойти незадействованное соединение, которое разрывается.

Так что, согласно первоначальному вопросу, лучший способ (я чувствую) справиться с этим - оставить тайм-аут на 4 минуты (так как ондолжен существовать в любом случае), а затем настройте инфраструктуру таким образом, чтобы корректно отключить ваши соединения (в режиме ожидания) до достижения времени балансировки нагрузкиout.

Наши решения

Для нашего блога Ghost (который попал в базу данных MySQL) мне удалось откатиться, как упоминалось выше, что позволило процессу Ghost обрабатывать сценарий отключения / переподключения БД,

А как насчет Rails?

Да.Та же проблема.

Для отдельного приложения на основе Rails мы также работаем на AKS, который подключается к удаленной базе данных Postgres (не в Azure), в итоге мы реализовали PGbouncer (https://github.com/pgbouncer/pgbouncer) в качестве дополнительного контейнера нанаш кластер с помощью удивительных указаний, найденных здесь: https://github.com/edoburu/docker-pgbouncer/tree/master/examples/kubernetes/singleuser

Как правило, любому, кто пытается получить доступ к удаленной базе данных из AKS, вероятно, понадобится внедрить промежуточное решение для пула соединений. Служба пулов находится посередине (PGbouncerдля нас) и следит за тем, как долго соединение простаивает, так что вашим рабочим процессам не нужно об этом заботиться.

Если вы начнете приближаться к тайм-ауту балансировщика нагрузки, служба пула подключений выброситстарое соединение и создайте новое новое (сброс таймера). Таким образом, когда ваш клиент отправляет данные по каналу, он попадает на ваш сервер базы данных, как и ожидалось.

При закрытии

Это былобезумно расстраивающая ошибка / случай, чтобы выследить. Мы сожгли по крайней мере 2 деv-ops дни, когда выяснялось первое решение, но даже Зная, что это, вероятно, та же проблема, мы сожгли еще 2 дня в этот раз.

Даже удлинение таймера сверх 4-минутного значения по умолчанию не помогло бы с тех порпросто сделает проблему более эфемерной для устранения неполадок.Полагаю, я просто надеюсь, что любой, у кого возникнут проблемы с подключением из Azure AKS / Kubernetes к удаленной базе данных, будет лучше гуглить, чем я, и может спасти себя от некоторой боли.

Благодаря поддержке MSFT (Крисявляются лучшими) для подсказки на таймере LB и чуваку, который собрал PGbouncer в контейнер, чтобы мне не пришлось изобретать велосипед.

...