Восстановление / повторная попытка в случае сбоя или зависания HTTP-запросов - PullRequest
0 голосов
/ 12 марта 2019

У меня есть сервер на базе Java, управляемый кластером kubernetes. Это распределенная среда, в которой номер экземпляра равен 4 для обработки миллионов запросов в минуту.

Проблема , с которой я сталкиваюсь, заключается в том, что kubernetes пытается сбалансировать кластер и в процессе убивает модуль и переносит его на другой узел, но есть ожидающий запрос HTTP GET и ПОЧТА, которая теряется.

Какое решение от kubernetes или архитектурного решения позволило бы мне повторить попытку, если запрос застрял / не прошел?

UPDATE:

У меня есть две конфигурации для службы kubernetes:

  1. LoadBalancer (с AWS ELB): для внешней облицовки
  2. ClusterIP: для внутренней архитектуры на основе микросервиса

Ответы [ 2 ]

0 голосов
/ 12 марта 2019

Сетка обслуживания решает конкретную проблему, с которой вы сталкиваетесь.

Доступны различные сетки обслуживания.Основные характеристики сетки обслуживания:

  • Балансировка нагрузки
  • Подробная политика трафика
  • Обнаружение службы
  • Мониторинг службы
  • Трассировка
  • Маршрутизация

Сетка обслуживания

  • Istio
  • Посланник
  • Linkerd

Linkerd: https://linkerd.io/2/features/retries-and-timeouts/

0 голосов
/ 12 марта 2019

Kubernetes дает вам возможность изящно обрабатывать окончания pod через SIGTERM и preStop hooks. Есть несколько статей на эту тему, например, Изящное отключение стручков с Kubernetes . В вашем Java-приложении вы должны прислушиваться к SIGTERM и корректно завершать работу сервера (большинство фреймворков http имеет встроенную функцию «выключения»).

Проблема, с которой я сталкиваюсь, заключается в том, что kubernetes пытается сбалансировать кластер и в процессе убивает модуль и переносит его на другой узел

Теперь это звучит немного подозрительно - в общем, K8s выселяет и перепланирует стручки на разных узлах при определенных обстоятельствах, например, когда у узла заканчиваются ресурсы для обслуживания стручка. Если ваши модули часто переносятся по расписанию, это, как правило, признак того, что что-то происходит, поэтому вам, вероятно, следует определить основную причину (если в спецификации развертывания установлены ограничения на ресурсы, убедитесь, что ваш служебный контейнер не превышает их - это является распространенной проблемой с контейнерами JVM).

Наконец, повторные попытки HTTP небезопасны для неидемпотентных запросов (POST / PUT), поэтому вы не можете просто повторить любой неудачный запрос, не зная логических последствий. В любом случае, повторные попытки обычно происходят на стороне клиента, а не на сервере, так что это не флаг, который вы можете установить в K8s, чтобы включить их.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...