If you are familiar with UNIX CronJob or Java Quartz (http://www.quartz-scheduler.org), Kubernetes CronJob is a very straightforward tool that you can use to define a particular timing to run your Kubernetes Job repeatedly.

The scheduling format is very simple; it specifies the following five items:

• Minutes (0 to 59)
• Hours (0 to 23)
• Days of the month (1 to 31)
• Months (1 to 12)
• Days of the week (0: Sunday to 6: Saturday)

For example, if you only want to run your Job at 9:00 am on November 12th every year to send a birthday greeting to me, the schedule format would be 0 9 12 11 *

You may also use a slash (/) to specify a step value. Running the previous Job example at five-minute intervals would have the following schedule format:

*/5  * * * *

The following template is using a CronJob to run the package-check command every five minutes:

$ cat cron-job.yaml 
apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: package-check-schedule
spec:
  schedule: "*/5 * * * *"
  concurrencyPolicy: "Forbid"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: package-check-schedule
            image: ubuntu
            command: ["dpkg-query", "-l"]
          restartPolicy: Never

$ kubectl create -f cron-job.yaml 
cronjob.batch/package-check-schedule created

You may notice that the template format is slightly different from the Job template here. However, there is one parameter we need to pay attention to: spec.concurrencyPolicy. With this, you can specify a behavior if the previous Job is not finished but the next Job's schedule is approaching. This determines how the next Job runs. You can set the following:

• Allow: Allow execution of the next Job
• Forbid: Skip execution of the next Job
• Replace: Delete the current Job, then execute the next Job

If you set Allow, there might be the potential risk of accumulating some unfinished Jobs in the Kubernetes cluster. Therefore, during the testing phase, you should set either Forbid or Replace to monitor Job execution and completion.

After a few moments, the Job will be triggered by your desired timing—in this case, every five minutes. You may then see the Job entry with the kubectl get jobs and kubectl get pods commands, as follows:

$ kubectl get jobs
NAME DESIRED  SUCCESSFUL  AGE
package-check-schedule-1537169100  1  1 8m
package-check-schedule-1537169400  1  1 3m

$ kubectl get pods
NAME READY  STATUS RESTARTS  AGE
package-check-schedule-1537169100-mnhxw  0/1  Completed  0 8m
package-check-schedule-1537169400-wvbgp  0/1  Completed  0 3m

CronJob will remain until you delete it. This means that, every five minutes, CronJob will create a new Job entry and related pods will also keep getting created. This will impact the consumption of Kubernetes resources. Therefore, by default, CronJob will keep up to three successful Jobs (with spec.successfulJobsHistoryLimit) and one failed Job (with spec.failedJobsHistoryLimit). You can change these parameters based on your requirements.

Overall, CronJob allows Jobs to automatically run in your application with the desired timing. You can utilize CronJob to run report-generation Jobs, daily or weekly batch Jobs, and so on.