A Job runs a finite task and finishes when the required number of pods complete successfully. Unlike a Deployment, which keeps pods running, a Job replaces a pod that disappears before finishing. Use one when a database import or other one-off task must reach completion without someone watching its pod. section 18.1 section 18.1.1
Run a database initialization
Define a batch/v1 Job with a Pod template and restartPolicy: OnFailure. One example first initializes a MongoDB replica set in an init container, then imports quiz questions in the main container. Run kubectl get jobs to watch COMPLETIONS change from 0/1 to 1/1. Use kubectl get pods -l job-name=quiz-init to find its completed pod, or kubectl logs job/quiz-init --all-containers --prefix to inspect both containers. section 18.1.1
Adjust how many successful runs the Job needs:
- spec.completions sets the required successful pod completions; spec.parallelism limits how many pods run at once. Both default to one. For five completions with parallelism two, a new pod can start as another finishes. section 18.1.2
- With restartPolicy: OnFailure, the Kubelet restarts a failed container in its pod. With Never, the pod fails and the Job controller creates a replacement. A Job can also fail after its backoff limit or active deadline is reached. section 18.1.3
- Set completionMode: Indexed when pods need distinct portions of the work. Each gets a completion index; a replacement for a failed index keeps that index. NonIndexed, the default, does not distinguish pod assignments. section 18.1.4
Table 18.1 Completions and parallelism combinations
|
Completions
|
Parallelism
|
Job behavior
|
|---|---|---|
|
Not set
|
Not set
|
A single pod is created, same as when
completions and
parallelism is
1.
|
|
1
|
1
|
A single pod is created. If the pod completes successfully, the Job is complete. If the pod is deleted before completing, it’s replaced by a new pod.
|
|
2
|
5
|
Only three pods are created, the same as if parallelism was 2.
|
|
5
|
2
|
Two pods are created initially. When one of them completes, the third pod is created. There are again two pods running. When one of the two completes, the fourth pod is created. There are again two pods running. When another one completes, the fifth and last pod is created.
|
|
5
|
5
|
Five pods run simultaneously. If one of them is deleted before it completes, a replacement is created. The Job is complete when five pods complete successfully.
|
|
5
|
Not set
|
Five pods are created sequentially. A new pod is created only when the previous pod completes (or fails).
|
|
Not set
|
5
|
Five pods are created simultaneously, but only one needs to complete successfully for the Job to complete.
|
Compare completions and parallelism settings to see when pods run sequentially, concurrently, or as replacements. section 18.1.2
Divide response aggregation by month
An Indexed Job can request 12 completions with parallelism three. Its processing script reads JOB_COMPLETION_INDEX and uses the index to select a month. This lets one Job coordinate related tasks without creating a separate Job manifest for every month. section 18.1.4
For work assigned dynamically, pods can fetch items from a work queue implemented by the application—not by Kubernetes. A pod can process one item and exit, or repeatedly fetch items until the queue is empty. When pods must find specific peers, use an Indexed Job with a headless Service and set the Service name as the Pod template’s subdomain. section 18.1.5 section 18.1.6
A Job pod cannot complete while an ordinary, indefinitely running sidecar remains active. Define that sidecar in initContainers with restartPolicy: Always so it can stop after the main task finishes. A Job starts immediately unless suspended; use a CronJob to create Jobs on a schedule. Deleting a Job normally deletes its pods, while --cascade=orphan preserves them. section 18.1.7 section 18.1.1 section 18.2
