#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:
Документация
- Из документации по повторным попыткам Istio: Значение по умолчанию
retry
жестко задано и равно 2.
Интервал между повторными попытками (25 мс ) является переменным и определяется автоматически Istio, предотвращая переполнение вызываемой службы запросами. Поведение повторной попытки по умолчанию для HTTP-запросов состоит в том, чтобы повторить попытку дважды, прежде чем возвращать ошибку.
Кстати, изначально он составлял 10, но уменьшился до 2 при включении повторных попыток для определенных кодов состояния и уменьшении числа повторных попыток до 2 фиксаций.
- обходной путь заключается в использовании виртуальных служб
вы можете настроить параметры повторных попыток для каждой службы в виртуальных службах, не касаясь кода службы. Вы также можете дополнительно уточнить поведение при повторных попытках, добавив тайм-ауты для каждой повторной попытки, указав количество времени, которое вы хотите ждать для каждой попытки повторной попытки успешного подключения к службе.
Примеры
- В следующем примере настраивается максимум 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
- Твое дело. Отключение повторных попыток. Взято из политики глобального отключения повторных попыток по умолчанию:
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. Но я мог бы пропустить эту политику по умолчанию, изменив ответ кода состояния на уровне приложения. Я не горжусь этим, но это единственное решение, которое я там нашел.