10.17 Kubernetes Job Controller

Kubernetes Job Controller is the workload controller responsible for managing Pods that must run a task to completion rather than persist indefinitely, creating one or more Pods to execute the specified work, tracking their success or failure, and retrying failed attempts up to a configured limit until the Job's completion criteria are satisfied.

Run-to-Completion Semantics

Success as the Terminal Goal

Unlike Deployments or ReplicaSets, which aim to keep a fixed number of Pods continuously running, a Job's objective is to have its Pods reach successful completion, meaning a container exiting with a zero status code is treated as the desired outcome rather than a failure requiring restart or replacement.

No Restart After Success

Once a Job's completion criteria have been satisfied, the controller does not create any further Pods, and existing successful Pods are not restarted, distinguishing this permanently terminal success state from the continuously monitored steady state maintained by long-running workload controllers.

Completion Modes

Single Completion

By default, a Job is satisfied by a single successful Pod completion, appropriate for straightforward one-off tasks where a single execution accomplishes the entire piece of work without any need for parallelism.

Fixed Completion Count

Setting the completions field to a value greater than one requires that many successful Pod completions before the Job is considered done, useful for tasks that can be broken into a known number of independent units of work, each handled by a separate Pod.

Work Queue Pattern

Without a fixed completions value but with parallelism set greater than one, Pods coordinate among themselves, often through an external work queue, to determine when all necessary work has been completed, with the Job considered done once any one Pod exits successfully and no other Pods are still processing.

Parallelism Control

The parallelism Field

The parallelism field specifies how many Pods the Job controller attempts to run concurrently at any given time, allowing a Job's total work to be distributed across multiple simultaneous executions rather than being processed strictly one Pod at a time.

Interaction Between Parallelism and Completions

When both completions and parallelism are set, the controller maintains up to the specified parallelism level of concurrently running Pods until the total number of successful completions reaches the required count, after which no further Pods are created even if some are still running.

Retry and Failure Handling

backoffLimit

The backoffLimit field specifies how many times the Job controller will retry creating a replacement Pod after a failure before giving up and marking the Job itself as failed, with retries subject to an exponential backoff delay similar to that applied to ordinary container restarts.

Pod Failure Policy

The podFailurePolicy field allows finer-grained control over how specific failure conditions, such as a particular container exit code or a Pod disruption caused by node eviction, are handled, enabling a Job to distinguish between failures that should count toward the retry limit and those that should not.

Active Deadline and Timeout Control

activeDeadlineSeconds

The activeDeadlineSeconds field imposes an overall time limit on the Job's execution, measured from when the Job starts, after which the Job is terminated and marked as failed regardless of how many Pods have successfully completed, providing a safeguard against tasks that run indefinitely longer than expected.

Cleanup Behavior

ttlSecondsAfterFinished

The ttlSecondsAfterFinished field, when set, causes the Job and its associated Pods to be automatically deleted a specified duration after the Job reaches a finished state, whether successful or failed, helping prevent the accumulation of completed Job objects that would otherwise persist indefinitely until manually cleaned up.