Вопросы Теги

Соединение некорректно сохраняется при использовании gRPC на ISTIO

Мы наблюдали странное поведение в нашем кластере кубернетов. У нас есть два тестовых приложения, говорящих на gRPC. Один отправляет сообщение о подписке, а другой отправляет обратно поток ответов. Предполагаемое поведение заключается в том, что этот поток остается активным до тех пор, пока не будет отменен. Однако мы обнаружили ситуации, когда сервер думал, что отправляет обновления, но клиент их не получал. Дальнейшее сужение этого параметра привело к воспроизводимому тесту:

  • Если служба настроена как gRPC в Kubernetes, то есть grpc- в имени порта.
  • Вы настраиваете потоковую передачу
  • Затем вы перезагружаете сервер

Затем наблюдаемое поведение заключалось в том, что клиент никогда не видел разрыва соединения, предположительно из-за того, что он подключен к прокси istio, а не к серверу назначения. Однако без информации о том, что соединение было прервано, оно не может восстановить соединение.

Кто-нибудь видел такое поведение? Что нам нужно настроить в ISTIO, чтобы обойти эту проблему? (Мы можем решить эту проблему, просто изменив службу так, чтобы имя порта не начиналось с "grpc-", но работало, отключив функциональность ISTIO gRPC.)

Изменить:

Kubernetes: 1.14.6 Istio: 1.3.6

Нет явной настройки DestinationRule, хотя мы пробовали разные вещи, мы не смогли найти ничего, что изменило бы это поведение.

0
задан 21 February 2020 в 13:27
1 ответ

] Этого можно было избежать, установив параметр idleTimeout в DestinationRule .

Согласно документации istio о idleTimeout :

тайм-аут для соединений пула восходящих соединений. Тайм-аут простоя определяется как период, в течение которого нет активных запросов. Если не установлен, тайм-аут простоя отсутствует. Когда истечет время ожидания простоя, соединение будет закрыто. Обратите внимание, что тайм-ауты на основе запросов означают, что HTTP / 2 PING не поддерживает соединение. Применяется как к соединениям HTTP1.1, так и к HTTP2.

Итак, если вы сделаете DestinationRule следующим образом: 

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: grpc-iddletimeout-policy
spec:
  host: grpcservice.servicenamespace.svc.cluster.local
  trafficPolicy:
    connectionPool:
      http:
        idleTimeout: 2m

Это должно закрыть любое соединение HTTP / 2 со стороны прокси-сервера Istio envoy после простоя в течение 2 минут для grpcservice в пространстве имен servicenamespace .

Istio также имеет tcpKeepalive , но я не уверен, будет ли он работать с Соединение grpc и Ваша конфигурация. 

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: grpc-iddletimeout-policy
spec:
  host: grpcservice.servicenamespace.svc.cluster.local
  trafficPolicy:
    connectionPool:
      tcp:
        connectTimeout: 30ms
        tcpKeepalive:
          time: 7200s
          interval: 75s
      http:
        idleTimeout: 2m

Обратите внимание, что параметр tcpKeepalive применяется на уровне TCP, а idleTimeout - на уровне HTTP / 2.

Вы можете проверить здесь , чтобы узнать, какие конкретные параметры TCPKeepalive доступны.

Также есть статья об использовании gRPC ] с соединением keepalive .

Надеюсь, это поможет.

1
ответ дан 26 February 2020 в 00:36

Теги

Похожие вопросы