ISTIO sidecar приводит к тому, что клиент grpc Java выдает «UNAVAILABLE: ошибка восходящего соединения или отключение / сброс перед заголовками» при высокой нагрузке параллелизма - PullRequest
Новая
       35

ISTIO sidecar приводит к тому, что клиент grpc Java выдает «UNAVAILABLE: ошибка восходящего соединения или отключение / сброс перед заголовками» при высокой нагрузке параллелизма

0 голосов
/ 09 января 2019

У меня есть две службы gRPC, и одна будет вызывать другую с помощью обычного метода gRPC (без потока с обеих сторон), я использую istio в качестве сетки служб, и мне вставили коляску в модуль kubernetes обеих служб.

Вызов gRPC корректно работает при нормальной нагрузке, но в ситуациях с высокой одновременной загрузкой клиентская сторона gRPC продолжает выдавать следующее исключение: 

<#bef7313d> i.g.StatusRuntimeException: UNAVAILABLE: upstream connect error or disconnect/reset before headers
    at io.grpc.Status.asRuntimeException(Status.java:526)
    at i.g.s.ClientCalls$StreamObserverToCallListenerAdapter.onClose(ClientCalls.java:434)
    at i.g.PartialForwardingClientCallListener.onClose(PartialForwardingClientCallListener.java:39)
    at i.g.ForwardingClientCallListener.onClose(ForwardingClientCallListener.java:23)
    at i.g.ForwardingClientCallListener$SimpleForwardingClientCallListener.onClose(ForwardingClientCallListener.java:40)
    at i.g.i.CensusStatsModule$StatsClientInterceptor$1$1.onClose(CensusStatsModule.java:678)
    at i.g.PartialForwardingClientCallListener.onClose(PartialForwardingClientCallListener.java:39)
    at i.g.ForwardingClientCallListener.onClose(ForwardingClientCallListener.java:23)
    at i.g.ForwardingClientCallListener$SimpleForwardingClientCallListener.onClose(ForwardingClientCallListener.java:40)
    at i.g.i.CensusTracingModule$TracingClientInterceptor$1$1.onClose(CensusTracingModule.java:397)
    at i.g.i.ClientCallImpl.closeObserver(ClientCallImpl.java:459)
    at i.g.i.ClientCallImpl.access$300(ClientCallImpl.java:63)
    at i.g.i.ClientCallImpl$ClientStreamListenerImpl.close(ClientCallImpl.java:546)
    at i.g.i.ClientCallImpl$ClientStreamListenerImpl.access$600(ClientCallImpl.java:467)
    at i.g.i.ClientCallImpl$ClientStreamListenerImpl$1StreamClosed.runInContext(ClientCallImpl.java:584)
    at i.g.i.ContextRunnable.run(ContextRunnable.java:37)
    at i.g.i.SerializingExecutor.run(SerializingExecutor.java:123)
    at j.u.c.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
    at j.u.c.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at java.lang.Thread.run(Thread.java:748)

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

Может ли кто-нибудь любезно сказать мне, почему и как решить эту проблему?

Большое спасибо.

1 Ответ

0 голосов
/ 11 января 2019

Наконец-то я нашел причину, это вызвано настройками по умолчанию circuitBeakers посланника коляски, по умолчанию опция max_pending_requests и max_requests установлена ​​на 1024, а по умолчанию connecTimeout равна 1s Таким образом, в ситуации высокой нагрузки параллелизма, когда на стороне сервера слишком много ожидающих запросов, ожидающих обработки, сторонний коммутатор схем подключится и скажет клиентской стороне, что восходящий поток на стороне сервера равен UNAVAILABLE.

Чтобы решить эту проблему, вам нужно применить DestinationRule для целевой службы с разумными настройками trafficPolicy.

...