У нас странная проблема с сетью.
У нас есть клиентское приложение Hyperledger Fabric, написанное на Node.js и работающее в Kubernetes, которое взаимодействует с внешней сетью Hyperledger Fabric.
Мы случайно получаем ошибки тайм-аута в этом сообщении. Когда модуль перезапускается, все идет хорошо какое-то время, затем начинаются ошибки тайм-аута, иногда случайным образом исправляемые сами по себе, а затем снова сбой.
Это Azure EKS, мы настроили быстрый кластер Kubernetes в AWS с помощью Rancher и развернули приложение там, и там произошла такая же ошибка тайм-аута.
Мы запускали скрипты в одном и том же контейнере всю ночь, которые каждую минуту попадали во внешнюю конечную точку Hyperledger с помощью cURL и небольшого скрипта Node.js, и мы не получили ни одной ошибки.
Мы запустили приложение на другой виртуальной машине как простые контейнеры Docker, и там не было никаких проблем.
Мы проверили сетевой трафик внутри контейнера, когда эта проблема возникает, мы можем видеть с помощью netstat, что соединение установлено, но tcpdump не показывает трафика, пакеты даже не отправляются.
Проверяя код SDK Hyperledger Fabric, он незаметно использует буферы протокола gRPC.
Так что, может быть, какие-нибудь подсказки?
другие части приложения также работают в одном кластере в разных модулях, например пользовательский интерфейс и т. д.
Оказалось, что это не Kubernetes, а проблема с подключением.
gRPC сохраняет соединение открытым, и после некоторого периода бездействия промежуточные компоненты разрывают соединение. В случае Azure AKS это балансировщик нагрузки, поскольку каждое исходящее соединение проходит через балансировщик нагрузки. Существует не настраиваемый период ожидания простоя в 4 минуты, после которого балансировщик нагрузки разрывает соединение.
Исправление заключается в настройке gRPC для отправки сообщений проверки активности.
Скрипты в контейнере работали без проблем, поскольку они открывают новое соединение при каждом запуске.
Приложение, работающее как простые контейнеры Docker, не имело этой проблемы, так как мы каждую минуту обращались к конечным точкам, следовательно, никогда не достигали порогового значения тайм-аута простоя. Когда мы обращаемся к конечным точкам каждые 10 минут, проблема с тайм-аутом тоже начиналась.
Это единственное приложение, работающее на вашем кластере AKS? или у вас есть еще приложения?