Job Parallelism and Completions
How does a Job run a batch of work to completion instead of serving forever? You give it completions, the number of successful runs you need, and parallelism, how many Pods may run at once, and it keeps launching Pods and retrying failures until that target is met. Once enough runs succeed it stops on its own and marks the batch complete. A failed Pod counts against backoffLimit, 6 by default, and exceeding that limit fails the Job instead.
Play the animation 5 steps, animated, best on a wide screen
Job Parallelism and Completions, step by step
-
A Job with a fixed completion count runs Pods until that many of them succeed. This one asks for 5 successful runs and allows 3 at a time, so the controller sees 0 Pods running against a parallelism of 3 and creates 3 from one Pod template. Nothing has finished yet, so no completion is recorded and .status.active is 3.
Play from step 1 -
Two runs finish cleanly: resize-images-x7k2p and resize-images-m4qbz exit 0. A Pod run that ends successfully counts once toward .spec.completions, so .status.succeeded moves from 0 to 2. A Pod that has succeeded is never restarted or reused, so the Job reaches the next completion by creating a new one.
Play from step 2 -
The third run fails: resize-images-t9dhw exits 1. Under restartPolicy Never a failing Pod reaches phase Failed, so .status.failed increments and no completion is recorded, and that failure counts against .spec.backoffLimit, 6 by default. The Pod object is kept rather than deleted, so its logs and its exit code stay readable.
Play from step 3 -
Three completions are still owed and no Pod is running, so the controller creates 3 new Pods, which is the parallelism cap again. The failure delayed all three, not only the retry: the back-off is 10s after one failure since the last success, then 20s, 40s and on, capped at ten minutes.
Play from step 4 -
The last three Pods exit 0 and .status.succeeded reaches 5, which equals .spec.completions. The controller stops creating Pods and records the condition Complete=True. The one earlier failure stays counted, and the Job and its Pods stay until deleted, or until ttlSecondsAfterFinished runs out if it is set.
Play from step 5