Отключить стратегию повторных попыток Istio по умолчанию (по крайней мере, для запросов POST)

#kubernetes #microservices #istio #envoyproxy #istio-sidecar

Вопрос:

У меня есть приложение (на основе микросервисов), работающее в kubernets с Istio 1.7.4

Микросервисы имеют свои собственные механизмы компенсации транзакций при сбоях интеграции.

Но Istio повторяет запросы, когда у некоторых интеграций есть 503 ответа с кодом состояния. Мне нужно отключить его (по крайней мере, на ПОСТУ, который не является идентичным).

И пусть приложение позаботится об этом.

Но я перепробовал так много способов, но безуспешно. Кто-нибудь может мне помочь?

Комментарии:

1. можете ли вы предоставить информацию о том, что вы пробовали?

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

3.Я пробовал это: discuss.istio.io/t/disable-globally-the-default-retry-policy/… И другие варианты этой политики, изменяющие атрибуты (условия retry_on и коды retriable_status_codes) Я также читал, что у Istio была ошибка при проверке этой политики, из-за которой невозможно было изменить попытки приписывания на ноль. Смотри: github.com/istio/istio/issues/14900 github.com/istio/istio/issues/13851

4. Похоже, ошибка все еще присутствует в Istio 1.7.4

5. Но я мог бы пропустить эту политику по умолчанию, изменив ответ кода состояния на уровне приложения. Я не горжусь этим, но это единственное решение, которое я там нашел.

Ответ №1:


Документация

Интервал между повторными попытками (25 мс ) является переменным и определяется автоматически Istio, предотвращая переполнение вызываемой службы запросами. Поведение повторной попытки по умолчанию для HTTP-запросов состоит в том, чтобы повторить попытку дважды, прежде чем возвращать ошибку.

Кстати, изначально он составлял 10, но уменьшился до 2 при включении повторных попыток для определенных кодов состояния и уменьшении числа повторных попыток до 2 фиксаций.

  • обходной путь заключается в использовании виртуальных служб

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


Примеры

  1. В следующем примере настраивается максимум 3 повторных попытки подключения к этому подмножеству служб после первоначального сбоя вызова, каждая с 2-секундным таймаутом.
 apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - route:
    - destination:
        host: ratings
        subset: v1
    retries:
      attempts: 3
      perTryTimeout: 2s
 
  1. Твое дело. Отключение повторных попыток. Взято из политики глобального отключения повторных попыток по умолчанию:
 apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: no-retries-for-one-service
spec:
  hosts:
  - one-service.default.svc.cluster.local
  http:
  - retries:
      attempts: 0
    route:
      - destination:
          host: one-service.default.svc.cluster.local
 

Комментарии:

1. Спасибо за ответ. Я пробовал это решение. И другие варианты этой политики, изменяющие атрибуты (условия retry_on и коды retriable_status_codes). Я также читал, что у Istio была ошибка при проверке этой политики, из-за которой невозможно было изменить попытки атрибута на ноль. Посмотрите здесь: ссылка и ссылка

2. Похоже, что ошибка все еще присутствует в Istio 1.7.4. Но я мог бы пропустить эту политику по умолчанию, изменив ответ кода состояния на уровне приложения. Я не горжусь этим, но это единственное решение, которое я там нашел.