Повторное использование проверки готовности зависимой службы для управления запуском службы

Question

У меня есть серверная служба, которую я буду контролировать с помощью Kubernetes (с диаграммой Helm). Эта внутренняя служба подключается к базе данных (MonogoDB, так бывает). Нет смысла запускать внутреннюю службу до тех пор, пока база данных не будет готова к приему соединения (серверная часть обработает недостающую базу данных, повторяя попытки, но тратит ресурсы и заполняет файл журнала отвлекающими факторами). Сообщения об ошибках).

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

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

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

Answer 1

Если я вас правильно понял. С точки зрения Mongo DB, с использованием readinessprobe все работает должным образом:

Согласно документации:

Кубелет использует зонды готовности, чтобы узнать, когда Контейнер готов начать принимать трафик. Под считается готовым, когда готовы все его контейнеры. Одно из применений этого сигнала - контролировать, какие модули используются в качестве серверных модулей для Сервисов. Когда Pod не готов, он удаляется из подсистем балансировки нагрузки службы.

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

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

В своем внутреннем развертывании вы можете комбинировать дополнительные тесты готовности, чтобы проверить, готово ли ваше основное развертывание для обслуживания трафика, вы можете использовать контейнер sidecar для обработки этого процесса (проверка подключения к основной службе базы данных и запись информации fe в статический файл за определенный период времени). В качестве примера взгляните на библиотеку EKG с сопроводительной записью mongoDBCheck. Или просто выполните команду exec в результате запуска вашего скрипта внутри контейнера sidecar:

readinessProbe:
  exec:
    command:
      - find
      - alive.txt
      - -mmin
      - '-1'
  initialDelaySeconds: 5
  periodSeconds: 15

Надеюсь на эту помощь