A Job in Kubernetes is designed to execute short-lived, one-time tasks that are meant to run until completion. It ensures that one or more Pods associated with it finish successfully. A Job can be considered a specialized type of Pod that runs a task once and then releases its resources.

Kubernetes supports several types of Jobs:

• Non-parallel Job: Typically creates a single Pod and waits for it to complete successfully.
• Fixed Completion Count Job: Sets .spec.completions to define how many successful Pods are required before the Job is marked as finished. Multiple Pods are created accordingly.
• Work Queue Parallel Job: Sets .spec.parallelism without specifying .spec.completions. The Job is considered successful when all Pods terminate and at least one has succeeded.

Based on the values of .spec.completions and .spec.parallelism, Jobs can be categorized into the following patterns:

Job Controller

The Job Controller is responsible for creating Pods based on the Job specification and monitoring their status until they complete successfully. If a Pod fails, the controller will decide whether to recreate it depending on the restartPolicy, wich only allows Never or OnFailure (not Always).

Job Specification Format

• The .spec.template follows the same structure as a Pod specification.
• Only Never or OnFailure are allowed for restartPolicy.
• When a single Pod is involved, the Job concludes upon successful completion of that Pod.
• .spec.completions defines how many Pods must complete successfully for the Job to end; default is 1.
• .spec.parallelism determines how many Pods may run concurrently; default is 1.
• .spec.activeDeadlineSeconds sets the maximum time a Job can remain active before being terminated if it hasn't completed.

Here’s an example of a basic Job:

apiVersion: batch/v1
kind: Job
metadata:
  name: calculate-pi
spec:
  template:
    metadata:
      name: pi-calculation
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never

To apply and check the output:

kubectl create -f job.yaml
pods=$(kubectl get pods --selector=job-name=calculate-pi --output=jsonpath={.items..metadata.name})
kubectl logs $pods

An example of a Job with fixed completions:

apiVersion: batch/v1
kind: Job
metadata:
  name: echo-hello
spec:
  completions: 3
  template:
    metadata:
      name: hello-worker
    spec:
      containers:
      - name: hello
        image: busybox
        command: ["echo", "hello"]
      restartPolicy: Never

Bare Pods

Bare Pods refer to those created directly using a Pod specification, outside of ReplicaSets or ReplicationControllers. These Pods do not automatically restart after a node failure. In contrast, Jobs manage the lifecycle of Pods and ensure that failed ones are replaced. Therefore, even for applications requiring just a single Pod, it is recommended to use Jobs instead of Bare Pods.