Chapter 33. Scheduled Jobs
33.1. Overview
A scheduled job builds on a regular job by allowing you to specifically schedule how the job should be run. Scheduled jobs are part of the Kubernetes API, which can be managed with oc commands like other object types.
As of OpenShift Container Platform 3.3.1, Scheduled Jobs is a feature in Technology Preview.
33.2. Creating a Scheduled Job
A scheduled job configuration consists of the following key parts:
- A schedule specified in cron format.
- A job template used when creating the next job.
- An optional deadline (in seconds) for starting the job if it misses its scheduled time for any reason. Missed jobs executions will be counted as failed ones. If not specified, there is no deadline.
ConcurrencyPolicy: An optional concurrency policy, specifying how to treat concurrent jobs within a scheduled job. Only one of the following concurrent policies may be specified. If not specified, this defaults to allowing concurrent executions.-
Allowallows Scheduled Jobs to run concurrently. -
Forbidforbids concurrent runs, skipping the next run if the previous has not finished yet. -
Replacecancels the currently running job and replaces it with a new one.
-
-
An optional flag allowing the suspension of a scheduled job. If set to
true, all subsequent executions will be suspended.
The following is an example of a ScheduledJob resource:
apiVersion: batch/v2alpha1 kind: ScheduledJob metadata: name: pi spec: schedule: */1 * * * ? 1 jobTemplate: 2 spec: template: metadata: labels: 3 parent: "schedjobpi" spec: containers: - name: pi image: perl command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] restartPolicy: OnFailure 4
- Schedule for the job. In this example, a job will run every minute.
- Job template. This is similar to the job example.
- Sets a label for jobs spawned by this scheduled job.
- The restart policy of the pod. This does not apply to the job controller. See Known Issues and Limitations for details.
You can also create and launch a scheduled job from a single command using oc run. The following command creates and launches the same scheduled job as specified in the previous example:
$ oc run pi --image=perl --schedule='*/1 * * * ?' \
--restart=OnFailure --labels parent="schedjobpi" \
--command -- perl -Mbignum=bpi -wle 'print bpi(2000)'
With oc run, the --schedule option accepts schedules in cron format.
When creating a scheduled job, oc run only supports the Never or OnFailure restart policies (--restart).
Delete scheduled jobs that you no longer need:
$ oc delete scheduledjob/<scheduledjob_name>
Doing this prevents them from generating unnecessary artifacts.
33.3. Cleaning Up After a Scheduled Job
Scheduled jobs can leave behind artifact resources such as jobs or pods. Check if any remain:
$ oc get jobs $ oc get pods
All artifacts left over from a job execution use the job name as their prefix. For example, given the scheduled job example:
$ oc get jobs NAME DESIRED SUCCESSFUL AGE pi-1497848100 1 1 1m pi-1497848160 1 1 49s $ oc get pods NAME READY STATUS RESTARTS AGE pi-1497848100-lxs4k 0/1 Completed 0 2m pi-1497848160-6r0c8 0/1 Completed 0 59s
Delete each artifact if you no longer need them. To delete all jobs spawned by a scheduled job, specify the label set during scheduled job creation:
$ oc delete jobs -l <label>
For example, to delete only the jobs generated by the scheduled job example:
$ oc delete jobs -l parent=schedjobpi job "pi-1497848100" deleted job "pi-1497848160" deleted
33.4. Known Issues
33.4.1. Unable to Edit a Scheduled Job
There is a known issue when invoking oc edit scheduledjob due to an error that was already fixed in the latest version. However, due to significant code changes, this was not backported.
One possible solution is to use oc patch command instead of oc edit.
33.4.2. Unable to Change Concurrency Policy
There is a known issue when changing concurrency policy where no new jobs are created after that operation is run. The issue is still under investigation in the latest version.

Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.