ждать запуска других развертываний, прежде чем можно будет создать другие?

Question

Я создаю развертывания / службы с использованием API REST. Я отправляю POST-запрос с телами, которые содержат объекты JSON, которые создают приложения на Openshift. После того, как я вызову все API, эти объекты будут созданы.

У меня есть 2 развертывания, которые зависят от развертывания mongodb, но запуск этого mongodb занимает немного больше времени, в то время как два развертывания, которые зависят от mongodb, запускаются раньше. Это нарушает код внутри 2 развертываний, поскольку соединение mongodb не удается (так как оно еще не установлено).

Возможны два способа решения этой проблемы.

1. Я ставлю задержку после создания развертывания mongodb и рекурсивно вызываю API, чтобы проверить его состояние, работает он или нет.

2. Точно так же, как мы вносим изменения в docker-compose с ключом, зависит от того, что сказать docker-compose, что сначала должны быть запущены все зависимости, а затем зависимый контейнер.

Есть ли способ, которым это может быть достигнуто в openshift?

Answer 1

Вместо реализации сложной логики для обработки зависимостей, используйте механизм проверки работоспособности Kubernetes. Если ваше приложение запускается и не видит БД Mongo, дайте ему сбой. Kubernetes будет продолжать перезапускать его до тех пор, пока Mongo DB не подключится к сети, и ваше приложение также станет работоспособным. Kubernetes не будет отправлять трафик еще не работающим экземплярам.

Документы: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/

Answer 2

Алекс указал на правильную практику, которой следует следовать с кубернетами. Но если вы все еще хотите напрямую зависеть от другого модуля phase, вы можете использовать этот pod-dependency-init-container, который я собрал. Это проверит, запущен ли какой-либо модуль с данным labels, прежде чем запускать его.

Answer 3

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

• Возможно, вы захотите заглянуть в Init Containers для зависимого контейнера. Они запускаются до завершения до фактического запуска контейнера. Ниже приведена выдержка из ссылочной документации (приведенной ниже) для случаев использования, которые могут быть применимы к вашей проблеме:

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

    Примеры

    Вот несколько идей о том, как использовать Init Containers:

    • Подождите, пока служба будет создана с помощью команды оболочки, такой как:

      for i in {1..100}; do sleep 1; if dig myservice; then exit 0; fi; done; exit 1
      

    • Зарегистрируйте этот Pod на удаленном сервере из нисходящего API с помощью команды вроде:

      curl -X POST http://$MANAGEMENT_SERVICE_HOST:$MANAGEMENT_SERVICE_PORT/register -d ‘instance=$()&ip=$()’
      

    • Подождите некоторое время, прежде чем запускать контейнер приложения с помощью команды, подобной sleep 60.

• Справочная документация:
  https://kubernetes.io/docs/concepts/workloads/pods/init-containers/