Когда cronjobs настроены на замену, ожидает ли Kubernetes завершения завершения предыдущего задания перед запуском нового?

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

Для справки, вот все документы, которые говорят о политике замены:

https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#concurrency-policy

Политика параллелизма

  • Заменить: если пришло время для нового выполнения задания, а предыдущее задание еще не завершено, задание cron заменяет запущенное в настоящее время задание на выполнение нового задания.

person Chris Morgan    schedule 09.12.2020    source источник


Ответы (1)


Краткое вступление / определение

  • Задания Cron ушли в давние времена в истории UNIX и Linux. В сочетании с другими технологиями Kubernetes, такими как модули, контейнеры, планировщик и интеллектуальные алгоритмы для размещения модулей и проверки работоспособности, CronJobs оказывается намного более мощным, чем их традиционные аналоги на уровне ОС.
  • Поскольку они работают в контейнерах, CronJobs предоставляет разработчикам большую гибкость. Им не нужно беспокоиться о том, на какой платформе выполняется задание cron, и о наличии необходимых зависимостей, поскольку все выполняется в контейнере.
  • Kubernetes обрабатывает выполнение CronJob, что происходит, когда он пропускает время выполнения, и сколько раз должно выполняться задание. Это позволяет разработчикам больше сосредоточиться на написании кода и решении бизнес-проблем, а не беспокоиться о внутренних деталях выполнения кода.
  • Бизнес-приложение по-прежнему отвечает за обработку того, что происходит, когда задание cron выполняется, не выполняется, отменяется или выполняется одновременно.

Подробнее читайте здесь: cronjob.

Что касается вашего вопроса, когда для CronJob установлена ​​политика параллелизма Replace и он все еще работает, Job будет удален, а также удаляет Pod - посмотрите code.

Пока Pod удаляет контейнер Linux / s будет отправлено SIGTERM, а затем SIGKILL после льготного периода, по умолчанию установлено 30 секунд. Свойство terminationGracePeriodSeconds в PodSpec можно установить, чтобы переопределить это значение по умолчанию.

Посмотрите на флаг в коде, который добавляется к _ 5_. Кажется, что это удаление удаляет только значения из хранилища ключей / значений kube. Это может означать, что новый модуль или задание может быть создан, в то время как текущий модуль или задание все еще завершается. Вы можете подтвердить задание, которое не соответствует SIGTERM и имеет _ 7_ установите скорость планирования кластера в несколько раз больше.

Взгляните на ответ @Matt: cronjob-shuttingdown.

person Malgorzata    schedule 10.12.2020