Случайные таймауты в приложении Node.js + gRPC в Куберне - PullRequest
Новая
       8

Случайные таймауты в приложении Node.js + gRPC в Куберне

0 голосов
/ 29 октября 2018

У нас странная проблема с сетью.

У нас есть клиентское приложение Hyperledger Fabric, написанное на Node.js, работающее в Kubernetes, которое взаимодействует с внешней сетью Hyperledger Fabric.

Мы случайно получаем ошибки тайм-аута в этом сообщении. Когда модуль перезапускается, некоторое время все идет хорошо, затем начинаются ошибки тайм-аута, иногда случайным образом исправляются сами по себе, а затем снова выходят из строя.

Это Azure EKS, мы настроили быстрый кластер Kubernetes в AWS с Rancher и развернули там приложение, и там тоже произошла ошибка тайм-аута.

Мы всю ночь запускали скрипты в одном и том же контейнере, который каждую минуту попадает во внешнюю конечную точку Hyperledger с помощью cURL и небольшого скрипта Node.js, и мы не получили ни единой ошибки.

Мы запустили приложение на другой виртуальной машине как простые контейнеры Docker, и там не было никаких проблем.

Мы проверили сетевой трафик внутри контейнера, когда эта проблема возникает, мы видим, что с помощью netstat установлено соединение, но tcpdump не показывает трафик, даже пакеты не пытаются отправлять.

Проверяя код Hyperledger Fabric SDK, он за кадром использует буферы протокола gRPC.

Значит, есть какие-нибудь подсказки?

1 Ответ

0 голосов
/ 02 ноября 2018

Оказалось, что это не Kubernetes, но проблема с удаленным соединением.

gRPC сохраняет соединение открытым, и после некоторого периода бездействия промежуточные компоненты сбрасывают соединение. В случае Azure AKS это балансировщик нагрузки, поскольку каждое исходящее соединение проходит через балансировщик нагрузки. Существует не настраиваемый период ожидания простоя 4 минуты, после которого балансировщик нагрузки прекращает соединение.

Исправление - настройка gRPC для отправки сообщений поддержки активности.

Скрипты в контейнере работали без проблем, так как они открывают новое соединение при каждом запуске.

Приложение, работающее как простые контейнеры Docker, не имело этой проблемы, так как мы выполняли операции с конечными точками каждую минуту, следовательно, никогда не достигали порога времени простоя. Когда мы достигаем конечных точек каждые 10 минут, там также начиналась проблема тайм-аута.

...