content_image/669193.jpg
Based on these two parameters, there are the following types of Jobs: 

Single Pod Job 

Fixed completion count Jobs 

Work queue Jobs 

<img src='content_image/669193.jpg'>

This type is selected when you leave out both .spec.completions  and .spec.par allelism  or set them to their default values of one. Such a Job starts only one Pod and is completed as soon as the single Pod terminates successfully (with exit code 0). 

When you specify .spec.completions  with a number greater than one, this many Pods must succeed. Optionally, you can set .spec.parallelism , or leave it at the default value of one. Such a Job is considered completed after the .spec.completions  number of Pods has completed successfully. Example 7-1 shows this mode in action and is the best choice when we know the number of work items in advance, and the processing cost of a single work item justifies the use of a dedicated Pod. 

You have a work queue for parallel Jobs when you leave out .spec.completions and set .spec.parallelism  to an integer greater than one. A work queue Job is considered completed when at least one Pod has terminated successfully, and all other Pods have terminated too. This setup requires the Pods to coordinate among themselves and determine what each one is working on so that they can finish in a coordinated fashion. For example, when a fixed but unknown number of work items is stored in a queue, parallel Pods can pick these up one by one to work on them. The first Pod that detects that the queue is empty and exits with success indicates the completion of the Job. The Job controller waits for all other Pods to terminate too. Since one Pod processes multiple work items, this Job type is an excellent choice for granular work items—when the overhead for one Pod per work item is not justified. 

If you have an unlimited stream of work items to process, other controllers like Repli‐ caSet are the better choice for managing the Pods processing these work items. 

