A job, in contrast to
a
deployment (or
a
replication controller), runs any number of pods to completion. A job tracks the
overall progress of a task and updates its status with information about active,
succeeded, and failed pods. Deleting a job will clean up any pods it created.
Jobs are part of the Kubernetes API, which can be managed with oc
commands like other
object types.
See the Kubernetes documentation for more information about jobs.
A job configuration consists of the following key parts:
-
A pod template, which describes the application the pod will create.
-
An optional
parallelism
parameter, which specifies how many pods running in parallel should execute a job. If not specified, this defaults to the value in thecompletions
parameter. -
An optional
completions
parameter, specifying how many successful pod completions are needed to finish a job. If not specified, this value defaults to one.
The following is an example of a job
resource:
apiVersion: batch/v1
kind: Job
metadata:
name: pi
spec:
parallelism: 1 (1)
completions: 1 (2)
template: (3)
metadata:
name: pi
spec:
containers:
- name: pi
image: perl
command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
restartPolicy: Never
-
Optional value for how many pods a job should run in parallel, defaults to
completions
. -
Optional value for how many successful pod completions is needed to mark a job completed, defaults to one.
-
Template for the pod the controller creates.
A job can be scaled up or down by using the oc scale
command with --replicas
option, which, in the case of jobs, modifies the spec.parallelism
parameter.
This will result in modifying the number of pods running in parallel, executing
a job.
The following command uses the example job above, and scales it to three:
$ oc scale job pi --replicas=3
Note
|
Scaling replication controllers also uses the oc scale command with the
--replicas option, but instead changes the replicas parameter of a
replication controller configuration.
|
When defining a Job
, you can define its maximum duration by setting
the activeDeadlineSeconds
field. It is specified in seconds and is not
set by default. When not set, there is no maximum duration enforced.
The maximum duration is counted from the time when a first pod gets scheduled in the system, and defines how long a job can be active. It tracks overall time of an execution and is irrelevant to the number of completions (number of pods needed to execute a task). After reaching the specified timeout, the job is terminated by {product-title}.
The following example shows the part of a Job
specifying
activeDeadlineSeconds
field for 30 minutes:
spec:
activeDeadlineSeconds: 1800