Managing cron tasks in Kubernetes

Kubernetes CronJobs provide much more precise control over scheduled tasks than traditional Linux crontabs. While both allow repeating jobs with specific timings, Kubernetes CronJobs:

• spin up a discrete container with its own resource limits to to run the job. This means that cron workloads are isolated from other workloads and don’t compete for CPU and memory resources with the frontend, for example.

• have built in concurrency prevention, disallowing a new job to start if the previous cron hasn’t completed, preventing race conditions.

• can be configured to retry on failure.

• are not well suited to long-running processes like message queue consumers — a microservice like RabbitMQ should be used instead.

• in case of errors you can see why a job failed to start or complete in the OKD console.

We strongly recommend using Kubernetes CronJobs for scheduled tasks for the above reasons.

Because the configuration for the entire Kubernetes environment comes from M.D.G. IT version controlled configuration files, we recommend having support set up the cron jobs that you need for you. If you need direct access to crons, there are several options available:

• A crontab like service can be installed on the SSH container. This gives direct access, however is discouraged since the advantages of Kubernetes CronJobs listed above are lost.

• (Advanced): we can provide access to the repository that defines your environment and crons, and you can modify the CronJob configuration directly. Please note that this does not delete existing crons — these need to be deleted in the OKD console.