1

I have a backup job running, scheduled to run every 24 hours. I have the concurrency policy set to "Forbid." I am testing my backup, and I create jobs manually for testing, but these tests are not forbidding concurrent runs. I use:

kubectl create job --from=cronjob/my-backup manual-backup-(timestamp)

... and when I run them twice in close succession, I find that both begin the work.

Does the concurrency policy only apply to jobs created by the Cron job scheduler? Does it ignore manually-created jobs? If it is ignoring those, are there other ways to manually run the job such that the Cron job scheduler knows they are there?

macetw
  • 1,640
  • 1
  • 17
  • 26
  • Does this answer your question? [Can manually triggered cron jobs respect the concurrencyPolicy?](https://stackoverflow.com/questions/67601223/can-manually-triggered-cron-jobs-respect-the-concurrencypolicy) – mozello Feb 02 '22 at 17:20
  • It certainly asks the same question, yes, but unfortunately it doesn't answer the important part at the bottom. In fact, an early answer here does somewhat answer the important part at the bottom. Good find. – macetw Feb 02 '22 at 23:50

1 Answers1

3

...Does the concurrency policy only apply to jobs created by the Cron job scheduler?

concurrencyPolicy applies to CronJob as it influences how CronJob start job. It is part of CronJob spec and not the Job spec.

...Does it ignore manually-created jobs?

Yes.

...ways to manually run the job such that the Cron job scheduler knows they are there?

Beware that when concurrencyPolicy is set to Forbid and when the time has come for CronJob to run job; but it detected there is job belongs to this CronJob is running; it will count the current attempt as missed. It is better to temporary set the CronJob spec.suspend to true if you manually start a job base out of the CronJob and the execution time will span over the next schedule time.

gohm'c
  • 13,492
  • 1
  • 9
  • 16