Длинный запрос возвращается с пустым ответом через 120 секунд, вызванным Network Load Balancer

У меня есть кластер GKE с 2 узлами, с сервисом типа LoadBalancer. Когда я звоню в сервис изнутри, длительный запрос не истекает через 120 секунд. Но если я вызываю внешний IP-адрес Network Load Balancer, который перенаправляет во внутреннюю службу, я получаю ответ "Пустой ответ от сервера".

Пример внешнего звонка:

curl -v "http://<public-ip>/longResponse"
*   Trying <public-ip>...
* TCP_NODELAY set
* Connected to <public-ip> (<public-ip>) port 80 (#0)
> GET /longResponse HTTP/1.1
> Host: <public-ip>
> User-Agent: curl/7.54.0
> Accept: */*
>
* Empty reply from server
* Connection #0 to host <public-ip> left intact
curl: (52) Empty reply from server

Пример внутреннего звонка:

/ # wget -O - -S <service-name>/longResponse
Connecting to location-service (10.3.255.181:80)
  HTTP/1.1 200 OK
  Access-Control-Allow-Origin: *
  Content-Type: application/json
  Content-Length: 15
  Date: Thu, 28 Feb 2019 10:31:14 GMT
  Connection: close

-                    100% |*********************************************************************************************************************************************************************************************************************|    15  0:00:00 ETA
/ #

Я попытался найти документацию для запроса или тайм-аута сокета на уровне балансировки нагрузки, но ничего не обнаружил. Любая идея?

Благодарю.

Источник

2 ответа

Получите имя бэкэнда балансировщика нагрузки:

gcloud compute backend-services list

затем

BACKEND=name-of-your-backend
gcloud compute backend-services update $BACKEND --timeout=600s

в противном случае в консоли: Network services ⇒ Load balancing ⇒ Backends затем вы можете щелкнуть свой HTTP-сервер и отредактировать настройки, включая время ожидания.

В более широком смысле, это может быть один из скачков сервала между сервером и клиентом, каждый из которых может иметь тайм-аут. Вам лучше либо жить с тайм-аутом (и завершать длинные опросы до истечения тайм-аута), либо выполнять непрерывную подачу данных по линии... например, вы можете предварительно отрендировать пробелы в json, поэтому, например, отправьте space характер каждые 30 секунд, пока у вас не будет правильного тела ответа. Это удержит баланс нагрузки от истечения времени ожидания.

Источник

Вы уверены, что это не тайм-аут на стороне клиента? Сетевой LB не обрабатывает пакеты, кроме как направляет их, поэтому он никогда не должен отправлять ответ.

Попробуйте -m флаг свернуться?

Также, возможно, запишите tcpdump на стороне клиента, чтобы вы могли видеть, что на самом деле делает сеть.

Источник
Другие вопросы по тегам