Службы на основе REST, работающие как модули в Kubernetes в Azure с периодическими тайм-аутами

Question

У нас есть несколько различных служб на основе REST, работающих в Azure в кластере Kubernetes (версия 1.9.6).

Две службы, скажем, A и B, должны общаться друг с другом с помощью REST-вызовов.Как правило, что-то вроде следующего:

Client calls A (original request)
A calls B (request 1)
B calls A (request 2)
A responds to B (request 2)
B responds to A (request 1)
A responds to the original request

Выше приведена типичная переплетенная архитектура микросервисов.Запуск экземпляров докера вручную прекрасно работает на наших локальных тестовых серверах.

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

Я застрял в этом моменте, так как понятия не имею, что может быть причиной этого.Может ли это быть динамическая маршрутизация?Виртуализированная сеть?Конфигурация Кубернетес?

Есть идеи?

Answer 1

Так что я тоже столкнулся с этим.

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

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

В моем случае AKS (или, возможно, Kubernetes) отключался /через некоторое время разорвать соединение блога Ghost с моей базой данных, но не уведомить службу, что привело к странным ошибкам, связанным с тем, что служба не осознает, что она была отключена, и не может продолжать использовать соединение, которое она ожидает, чтобы быть доступным / открытым.

Это не решение, а просто дополнительная справка!

Я спорю, стоит ли открывать заявку на Azure AKS GitHub (и с моей подпиской на службу поддержки), чтобы запросить дополнительную информацию.Если я отвечу, я обновлю этот ответ!

Answer 2

Наконец-то понял это.

Балансировщики нагрузки Azure / общедоступные IP-адреса имеют по умолчанию 4-минутное время ожидания простоя.

По сути, все, что выполняется через балансировщик нагрузки (независимо от того, создан ли он при помощи Azure AKS Kubernetes Ingress или иным образом), должен соблюдать это.Несмотря на то, что вы МОЖЕТЕ изменить время ожидания, невозможно полностью его исключить (максимально возможное время простоя составляет 30 минут).

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

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

В целом я вижу необходимость в тайм-ауте, но MAN трудно было устранить неисправностьНадеюсь, что это сэкономит вам время, ребята!

Более подробную информацию можно найти в моем полном посте здесь: Что происходит в «Тайм-аут» Azure Kubernetes (AKS) для разъединения соединений в / изСтручок в моем кластере?

Answer 3

Как вы описываете, это, вероятно, не проблема докера или kubernetes.Вместо этого вы должны проверить, отвечает ли B на A, прежде чем A ответит на B, и если так, проверьте, не отвечает ли A на исходный вызов.

Вы можете настроить журналы, чтобы увидеть, происходит ли это,или отладьте его, если вы можете воспроизвести его на своем компьютере.