я есть работающий кластер со службами, которые все отвечают за установленным рулем Ingress nGinx, работающим на Azure AKS.Это в конечном итоге специфично для Azure.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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