Running Automated Tasks with a CronJob

    Cron jobs are useful for creating periodic and recurring tasks, like running backups or sending emails. Cron jobs can also schedule individual tasks for a specific time, such as if you want to schedule a job for a low activity period.

    Cron jobs have limitations and idiosyncrasies. For example, in certain circumstances, a single cron job can create multiple jobs. Therefore, jobs should be idempotent.

    For more limitations, see CronJobs.

    • You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. It is recommended to run this tutorial on a cluster with at least two nodes that are not acting as control plane hosts. If you do not already have a cluster, you can create one by using minikube or you can use one of these Kubernetes playgrounds:

    Cron jobs require a config file. Here is a manifest for a CronJob that runs a simple demonstration task every minute:

    application/job/cronjob.yaml

    Run the example CronJob by using this command:

    The output is similar to this:

    1. cronjob.batch/hello created

    After creating the cron job, get its status using this command:

    1. kubectl get cronjob hello

    The output is similar to this:

    As you can see from the results of the command, the cron job has not scheduled or run any jobs yet. Watch for the job to be created in around one minute:

    1. kubectl get jobs --watch
    1. NAME               COMPLETIONS   DURATION   AGE
    2. hello-4111706356   0/1                      0s
    3. hello-4111706356   1/1           5s         5s

    Now you’ve seen one running job scheduled by the “hello” cron job. You can stop watching the job and view the cron job again to see that it scheduled the job:

    1. kubectl get cronjob hello

    The output is similar to this:

    You should see that the cron job hello successfully scheduled a job at the time specified in LAST SCHEDULE. There are currently 0 active jobs, meaning that the job has completed or failed.

    Now, find the pods that the last scheduled job created and view the standard output of one of the pods.

    Note: The job name is different from the pod name.

    1. # Replace "hello-4111706356" with the job name in your system
    2. pods=$(kubectl get pods --selector=job-name=hello-4111706356 --output=jsonpath={.items[*].metadata.name})

    Show the pod log:

    1. kubectl logs $pods

    The output is similar to this:

    1. Fri Feb 22 11:02:09 UTC 2019
    2. Hello from the Kubernetes cluster

    When you don’t need a cron job any more, delete it with :

    Deleting the cron job removes all the jobs and pods it created and stops it from creating additional jobs. You can read more about removing jobs in garbage collection.

    As with all other Kubernetes objects, a CronJob must have apiVersion, kind, and metadata fields. For more information about working with Kubernetes objects and their manifests, see the , and using kubectl to manage resources documents.

    Each manifest for a CronJob also needs a section.

    The .spec.schedule is a required field of the .spec. It takes a format string, such as 0 * * * * or @hourly, as schedule time of its jobs to be created and executed.

    The format also includes extended “Vixie cron” step values. As explained in the FreeBSD manual:

    Note: A question mark (?) in the schedule has the same meaning as an asterisk *, that is, it stands for any of available value for a given field.

    Job Template

    The .spec.jobTemplate is the template for the job, and it is required. It has exactly the same schema as a Job, except that it is nested and does not have an apiVersion or . For information about writing a job .spec, see .

    The .spec.startingDeadlineSeconds field is optional. It stands for the deadline in seconds for starting the job if it misses its scheduled time for any reason. After the deadline, the cron job does not start the job. Jobs that do not meet their deadline in this way count as failed jobs. If this field is not specified, the jobs have no deadline.

    If the .spec.startingDeadlineSeconds field is set (not null), the CronJob controller measures the time between when a job is expected to be created and now. If the difference is higher than that limit, it will skip this execution.

    For example, if it is set to 200, it allows a job to be created for up to 200 seconds after the actual schedule.

    Concurrency Policy

    The .spec.concurrencyPolicy field is also optional. It specifies how to treat concurrent executions of a job that is created by this cron job. The spec may specify only one of the following concurrency policies:

    • Allow (default): The cron job allows concurrently running jobs
    • Forbid: The cron job does not allow concurrent runs; if it is time for a new job run and the previous job run hasn’t finished yet, the cron job skips the new job run

    Note that concurrency policy only applies to the jobs created by the same cron job. If there are multiple cron jobs, their respective jobs are always allowed to run concurrently.

    The .spec.suspend field is also optional. If it is set to true, all subsequent executions are suspended. This setting does not apply to already started executions. Defaults to false.

    Jobs History Limits

    The .spec.successfulJobsHistoryLimit and .spec.failedJobsHistoryLimit fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 3 and 1 respectively. Setting a limit to corresponds to keeping none of the corresponding kind of jobs after they finish.