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 define a particular timing to run your Kubernetes Job repeatedly.

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

• Minutes (0 – 59)
• Hours (0 – 23)
• Day of Month (1 – 31)
• Month (1 – 12)
• Day of week (0: Sunday – 6: Saturday)

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

You may also use slash (/) to specify a step value; a run every 5 minutes interval for the previous Job example would have the following schedule format: */5 * * * *. 

In addition, there is an optional parameter, spec.concurrencyPolicy, that you can specify a behavior if the previous Job is not finished but the next Job schedule is approaching, to determine how the next Job runs. You can set either:

• 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 as Allow, there might be a 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:

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

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

$ kubectl get cronjob
NAME            SCHEDULE      SUSPEND   ACTIVE    LAST SCHEDULE   AGE
package-check   */5 * * * *   False     0         <none>

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

//around 9 minutes later, 2 jobs have been submitted already
$ kubectl get jobs
NAME                       DESIRED   SUCCESSFUL   AGE
package-check-1515571800   1         1            7m
package-check-1515572100   1         1            2m


//correspond Pod are remain and find by -a option
$ kubectl get pods -a
NAME                             READY     STATUS      RESTARTS   AGE
package-check-1515571800-jbzbr   0/1       Completed   0          7m
package-check-1515572100-bp5fz   0/1       Completed   0          2m

CronJob will keep remaining until you delete; this means that, every 5 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 3 successful Jobs (by spec.successfulJobsHistoryLimit) and one failed Job (by spec.failedJobsHistoryLimit). You can change these parameters based on your requirements.

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