0

I'm starting in Kubernetes and I have a question about the CronJob, in my project I need a cron job to be launched every minute. On many tutorials people use the CronJob resource, I set it up and I see that every minute a pod is created to perform the command and is then destroyed, and that indefinitely. I wonder if in my case (every minute) it's interesting to use the Kubernetes CronJob resource knowing that every minute a pod is created by pulling an image etc.... I find the process a bit cumbersome, isn't it better to have a simple pod executing the cron in the traditional way?

Youss
  • 95
  • 11

3 Answers3

2

Look at running a cronjob inside the pod instead of kubernetes CronJob. That way you don't have to bother about launching a new pod every minute.

Mark Watney
  • 5,268
  • 2
  • 11
  • 33
P Ekambaram
  • 15,499
  • 7
  • 34
  • 59
  • That's what I thought, it's better to have a pod with a crontab, and to launch my job in a traditional way rather than using the CronJob of kubernetes. – Youss Jun 10 '20 at 10:37
1

I prefer running cronjobs as native Kubernetes workload using CronJobs. Compared to running the job inside one pod, running as a CronJob allows Kubernetes to effectively manage the resources. As well as you can scale the number of jobs easily and you are not limited to one node.

However, you have to deal with failed jobs, overlapping jobs, idempotency, etc., which you have to solve with any scheduler.

Also, you can consider dedicated pods based on your business use case. If you are implementing a publisher-subscriber, then running dedicated containers makes sense. For simple jobs, CronJobs should work.

BTW, you don't need to worry about pulling images every time. You can specify the imagePullPolicy as IfNotPresent.

The image is pulled only if it is not already present locally.

Rajan Panneer Selvam
  • 1,279
  • 10
  • 24
0

I think the trade-off depends on how frequently the cronjob will run and whether it is likely to do much work. If infrequent, why keep a pod sitting there doing nothing? Also, every time the job gets scheduled, the pod can be scheduled on a more suitable/empty/newer node whereas a deployment is going to generally leave that pod on the node it was scheduled on until you update it.

Monitoring tools are more likely to be geared towards native K8S cronjobs otherwise, how would you know that your jobs have been skipped/errored etc?

If more frequent and you want things like real-time logging etc. then a pod(s) via a deployment might be helpful instead.

Luke Briner
  • 708
  • 4
  • 21