Discovering Jobs in Kubernetes

You've already deployed different kinds of workloads to your Kubernetes cluster. However, for some use cases, you don't need a workload that is always running. Instead, you want to run a workload only once and then terminate it or schedule it to run periodically. To learn how to do this, explore the capabilities of Jobs in Kubernetes.

Jobs are used to run a workload only once. For example, you can use a Job to run a database migration or to perform a batch job. Compared to the other workloads in Kubernetes, Jobs are not supposed to be long-running. Instead, they are supposed to run to completion and then terminate. However, if a Job fails, it is restarted until it succeeds.

Click the buttons below to find out more about each Job type.

See a simple Job manifest to declare a one-off Job:

12345678910111213
apiVersion: batch/v1
kind: Job
metadata:
  name: my-job
spec:
  backoffLimit: 4
  template:
     spec:
       containers:
       - name: my-job
         image: busybox:1.35.0
         command: ['sh', '-c', 'echo Hello Kubernetes! && sleep 10 && echo Job done!']
       restartPolicy: OnFailure

The above manifest defines a Job that runs a single Pod with a container based on the busybox image. The container runs the command echo Hello Kubernetes! && sleep 10 && echo Job done!. The restartPolicy is set to OnFailure, which means that the Job is restarted if it fails. Alternatively, you can set the restartPolicy to Never, which means that the Job is not restarted if it fails. The backoffLimit is set to 4, meaning the Job is restarted at most four times. If the Job fails 4 times, it is marked as failed.

When defining a parallel Job, you can specify the number of parallel Pods that must be created in total (.spec.parallelism) and the maximum number of parallel Pods that should be running simultaneously (.spec.completions). The following manifest defines a parallel Job that creates six Pods in total and runs three Pods in parallel:

123456789101112131415161718
apiVersion: batch/v1
kind: Job
metadata:
   name: my-parallel-job
spec:
   parallelism: 3
   completions: 6
   backoffLimit: 4
   template:
     metadata:
       labels:
         sidecar.istio.io/inject: "false"
     spec:
       containers:
       - name: my-parallel-job
         image: busybox:1.35.0
         command: ['sh', '-c', 'echo Hello Kubernetes! && sleep 10 && echo Job done!']
       restartPolicy: Never

Kubernetes also waits until all three Pods have been completed successfully before it starts the next three Pods.

You can also observe this in Kyma dashboard. In the namespace of your choice, go to Workloads > Jobs, choose Create, and paste the above Job manifest. You can see that first only three Pods are running. Once these Pods are set to the Completed status, three more Pods are created. When these additional Pods complete their tasks, all six Pods are in the Completed status.

For scheduling a workload to run periodically, you can use a CronJob. A CronJob is similar to a Job but is scheduled to run regularly at a fixed time, date, or specific time interval. The following manifest defines a CronJob that runs every night at 2:00 AM:

1234567891011121314151617

apiVersion: batch/v1beta1
 kind: CronJob
 metadata:
   name: my-cronjob
 spec:
   schedule: "0 2 * * *"
   jobTemplate:
     spec:
       template:
         spec:
           containers:
           - name: my-cronjob
           image: busybox:1.35.0 # busybox is a small image that contains a few useful utilities
           command: ['sh', '-c', 'echo Hello Kubernetes! && sleep 10 && echo Job done!']
         restartPolicy: OnFailure
      backoffLimit: 4

The schedule field defines the schedule in the Cron format. In the above example, the CronJob is scheduled to run every night at 2:00 AM. The jobTemplate field defines the Job template used for the CronJob. The CronJob creates a Job based on this template and then schedules it to run periodically.

In Kubernetes, you can use Jobs to run workloads that are not long-running, but instead run to completion and then terminate. Jobs can be non-parallel, meaning they run a single Pod, or parallel, where multiple Pods run concurrently. Additionally, CronJobs allow for scheduling Jobs to run periodically at fixed times, dates, or intervals.