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

Question

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

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

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

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

Answer 1

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

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

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

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

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

В вашем внутреннем развертывании вы можете комбинировать дополнительные датчики готовности, чтобы проверить, готово ли ваше основное развертывание для обслуживания трафика, вы можете использовать контейнер с коляской для обработки этого процесса (проверка соединения с первичной службой БД и запись информации).в статическом файле за определенный период времени).В качестве примера рассмотрим библиотеку ЭКГ с коляской mongoDBCheck.Или просто выполните команду exec в результате выполнения вашего скрипта внутри контейнера с коляской:

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

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

Answer 2

Я бы посоветовал против такого подхода, поскольку службы в архитектуре микросервисов не должны вести себя (вот интересная статья на эту тему).

Что вы можетеУ do есть контейнеры, которые принадлежат бэкэнд-сервису, вызывают сервис базы данных, и, если последний не работает, аварийно завершают работу контейнеров.Используя возможности самовосстановления Kubernetes, контейнеры будут автоматически аварийно завершать работу и перезапускаться (с экспоненциальным откатом) до тех пор, пока не будет запущена служба базы данных.

Среди других преимуществ этот метод прощереализовать и уменьшить связь между службами.