Проверка работоспособности привода пружинной загрузки в Openshift / Kubernetes - PullRequest
Новая
       11

Проверка работоспособности привода пружинной загрузки в Openshift / Kubernetes

0 голосов
/ 14 февраля 2019

У нас есть ситуация, когда у нас имеется множество загрузочных приложений Spring, работающих в контейнерах (в OpenShift), которые обращаются к централизованной инфраструктуре (внешней по отношению к модулю), такой как базы данных, очереди и т. Д.

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

Я понимаю, что отключение центральной инфраструктуры являетсяплохо.Это "не должно" никогда не случиться.Но ... если это произойдет (закон Мерфи), он бросит контейнеры в безумие.Просто кажется, что мы либо делаем что-то не так, либо нам нужно что-то перенастроить.

Пара вопросов:

  • Если вы вынуждены использовать централизованную инфраструктуру из запущенного загрузочного приложения Springв контейнере в OpenShift / Kubernetes все ли проверки исполнительных механизмов все еще должны быть включены для бэкэнда?(подпрыгивание контейнера в действительности не исправит то, что бэкенд все равно был неактивным)
  • Должна ли конечная точка / actator / health быть настроена как для датчика живучести, так и для датчика готовности?
  • Какие общие настройки используютсянародное использование для проверки готовности / живости в приложении весенней загрузки?(тайм-ауты / интервал / и т. д.).

1 Ответ

0 голосов
/ 14 февраля 2019

  1. Использование проверок привода на предмет работоспособности / готовности является де-факто способом проверки работоспособности приложения в Spring Boot Pod.После запуска ваше приложение в идеале не должно выходить из строя или становиться нездоровым, если центральная часть, такая как БД или служба очередей, выходит из строя, в идеале вы должны добавить некоторую устойчивость, которая будет либо подключаться к альтернативному сайту DR, либо ждать некоторое времяпериод для восстановления центральной службы и повторного подключения приложения.Это скорее технический сбой на стороне сервера, вызывающий функциональный сбой вашего Приложения после его безошибочного запуска.

  2. Да, необходимы как живучесть, так и готовность, поскольку оба они служат разным целям,Прочитайте это

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

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

...