Слои таймаута в управляемом кластере Istio+k8s ⇐ JAVA

[Anonymous]

У меня есть кластер микросервисов. Пользовательский интерфейс вызывает API1 (при условии, что он проходит через входной шлюз, поправьте меня, если я ошибаюсь), API1 вызывает API2 через RestTemplate.
Процесс API2 громоздкий и занимает примерно 1,5 минуты, однако в самом процессе нет ошибок или исключений. В целях тестирования я вызвал API2 напрямую через Bruno (который установлен с достаточно большим значением тайм-аута), что приводит к зависанию сокета примерно на 1 минуту, что ожидаемо, поскольку время ожидания простоя соединения AWS LB составляет 1 минуту. Но на вкладке «Сеть» Chrome я вижу время успешного завершения вызова с ожиданием времени сервера равным 1,5 минутам.
Я понимаю, что в istio по умолчанию установлено 2 повторные попытки при сбоях соединения, а тайм-аут отключен. Мой вопрос в том, почему при вызове из пользовательского интерфейса он завершается успешно через 1,5 минуты, а не ждет 3 минуты и терпит неудачу. Поды ведут себя непонятно мне? Насколько я понимаю, через 1 минуту сокет закрывается и начинается повторная попытка, но это также должно завершиться неудачей и начать вторую повторную попытку. Опять же, это также должно потерпеть неудачу через следующую минуту. Сокет каким-то образом повторно открывается в течение общего времени 3x1=3 минуты, и вызов успешен, потому что он занимает менее 3 минут?
P.S. Я младший разработчик, который только знакомится с миром devops оркестрации кластеров, сервисной сетки и т. д. Мы будем очень признательны за любые разъяснения.
Я изменил время ожидания простоя соединения LB на более высокое значение, и вызов в Bruno прошел успешно, как и ожидалось. Я включил в процесс произвольно большое время ожидания и изменил значения времени ожидания простоя, чтобы получить ожидаемые результаты.
Но я не понимаю разницы, которую я вижу в Chrome (UI->API1->API2) и вызове (Bruno->API2).
Я прочитал документацию и поискал в Google удовлетворительного ответа.

Подробнее здесь: https://stackoverflow.com/questions/797 ... ed-cluster