Сервис Openshift недоступен после короткого простоя

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

  • Сервер маршрутизации (Spring Boot 1.5.8 с Zuul). Он принимает весь входящий трафик и направляет его в нужные службы.

  • Несколько сервисов (все с Spring Boot): здесь вся бизнес-логика

Мы используем SOAP для вызова других сервисов в этом проекте.

В настоящее время, когда мы вызываем приложение, вызов поступает на сервер маршрутизации, который затем направляет его в основной бизнес-сервис. После непродолжительного простоя, продолжавшегося около часа, наша основная бизнес-услуга недоступна через внешний звонок. Однако пограничный сервер доступен и может вызываться в 100% случаев. Мы получаем исключение 504 Gateway Timeout из системы, когда мы его вызываем. Мы уже выяснили, что это тайм-аут маршрута в openshift (haproxy.router.openshift.io/timeout в маршруте).

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

Как мы можем отключить это поведение?

Изменить 1:

  • У нас есть такое же приложение в обычных "старомодных" виртуальных машинах. У нас там нет проблем.
  • Мы заметили, что услуги можно "поддерживать в живых", когда мы называем их регулярными. Мы создали небольшой сервис, который называет тему регулярно (каждые 15 минут). Таким образом, это похоже на работу. Но это не готовый к работе обходной путь IMO.

Изменить 2:

Наш pod config (некоторые имена анонимны):

https://gist.github.com/moritzluedtke/6867499b0acbb2d7b5a9a70e49b0d45c

Мы не используем автоскалер.

Изменить 3:

Наши конфигурации развертывания (некоторые имена анонимны):

https://gist.github.com/moritzluedtke/dc7c1078fe9cc7e4aeb737094849fc1b

OpenShift Master:      v3.11.0+1c3e643-87
Kubernetes Master:     v1.11.0+d4cacc0
OpenShift Web Console: v3.11.0+ea42280

Изменить 4:

Похоже, что это не проблема OpenShift, а наш технический стек. Я обновлю этот вопрос, как только у нас будет решение.

ОТВЕТЫ