Добавить Pod в задание kubernetes, созданное CronJob

У меня есть CronJob, который запрещает параллелизм (concurrencyPolicy: Forbid). Теперь Pod, который запускается заданием самим CronJob, порождает Pod (который находится вне моего контроля), который, в свою очередь, также может или не может порождать Pod.

··········> ··········> time ··········> ··········>

CronJob
    |
    +-----------------------+----····
    |                       |
  schedules               schedules
    |                       |
    v                       v
first Pod ~~~> Exit.    first Pod ~~~> Exit.
    |                       |
  spawns                  spawns
    |                       |
    |                       ???? SECOND COMING OF SECOND POD CONCURRENT WITH FIRST
    v                       
second Pod ~~~~~~ still running ~~~~~~>

Теперь первый Pod выходит довольно быстро, оставляя контроллер CronJob под впечатлением, что задание выполнено. Но на самом деле работа все еще выполняется, поскольку она породила Pod. Таким образом, в следующий раз, когда задание будет запланировано CronJob, он может породить модуль, который будет запускаться одновременно с другими модулями, порожденными первым запланированным заданием. Именно это я и пытаюсь предотвратить.

Есть ли способ, которым мой первый модуль (у меня есть полный контроль над первым модулем, за исключением того факта, что он порождает модуль, и я не контролирую, что происходит в этом модуле или как он создается, но я могу установить метки и annotations) каким-то образом добавляет последовательно порождаемые модули к текущему заданию, так что оно считается завершенным только после того, как эти модули возвращаются?


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


person scravy    schedule 08.02.2021    source источник


Ответы (1)


Боюсь, kubernetes не справится с этим за вас. Я бы сказал скорее о логике приложения. Kubernetes Pod никоим образом не знает, что он породил другой Pod или что такой Pod был порожден им.

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

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

person mario    schedule 09.02.2021
comment
@scravy Это ответ на ваш вопрос? - person Wytrzymały Wiktor; 10.02.2021
comment
Как я сказал в своем вопросе, мой нынешний подход состоит в том, чтобы самому следить за этими модулями. Однако мне интересно, могу ли я исправить ресурс задания, чтобы также учесть созданные мной поды, чтобы мне не приходилось делать это самому. - person scravy; 11.02.2021
comment
Когда вы говорите, что Kubernetes Pod никоим образом не знает, что он породил другой Pod, вы имеете в виду, что Kubernetes Job не знает ...? - person scravy; 11.02.2021
comment
@ WytrzymałyWiktor Отвечает ли на ваш вопрос тот факт, что я не принял этот вопрос в качестве ответа? - person scravy; 11.02.2021