Jobs & CronJobs in Kubernetes

Credits: https://michael.bouvy.net/

There are broadly 2 types of workloads:

1. Longer running time workloads: DB, Services, Web-servers, etc. Manually stopped if required.
2. Short runtime workloads: Batch processing, analytics, reporting, etc. Stops after finishing the task.

Let us create a pod definition file (simple-sum.yaml) to do some computational work

apiVersion: v1
kind: Pod
metadata:
  name: math-pod
spec:
  containers:
  - name: math-add
    image: ubuntu
    command: [‘expr’, ‘3’, ‘+’, ‘2’]

Now lets run command:

kubectl apply -f simple-sum.yaml

Status of pod (kubectl get pods) changes from creating -> running -> completed.

But the problem is, as soon as the pod goes to completed state (since it is done with the operation), kubernetes restarts it and the cycle continues.

Because kubernetes wants to keep pods running forever by default. Hence there is a property called ‘restartPolicy’ which is set to ‘Always’ by default.

We can override this property to either ‘Never’ or ‘OnFailure’.

Jobs

1. We want to make sure that all pods doing some computational work get created and do a certain job successfully and then are dropped. For this we require a manager which is also known as a Job.
2. ReplicaSet ensure running pods forever while Job ensures creating pods and doing assigned tasks successfully.

An example of a Job

apiVersion: batch/v1
kind: Job
metadata:
  name: math-add-job
spec:
  completions: 3
  parallelism: 3
template:
  spec:
    containers:
    - name: math-add
      image: ubuntu
      command: [‘expr’, ‘3’, ‘+’, ‘2’]
    restartPolicy: Never

‘completions’ (in job) is analogous to ‘replicas’ (in replicaset or deployments).

If one of the pod fails, the Job tries spin up pods until required completions are not meant.

‘parallelism’ forces kubernetes to create pods for a Job at the same time.

CronJobs

1. A Job that can be scheduled is called CronJob.
2. Template of CronJob is as follows:

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: reporting-cron-job
spec:
  schedule: “30 21 * * *”
  jobTemplate:
    spec:
      completions: 3
      parallelism: 3
      template:
        spec:
          containers:
          - name: math-add
            image: ubuntu
            command: [‘expr’, ‘3’, ‘+’, ‘2’]
        restartPolicy: Never

schedule “30 21 * * *” implies that this ob will run at 2130 hrs everyday.

One thing to notice is that it has 3 ’spec’s.

1st spec is for CronJob itself.

2nd spec is for Job (because CronJob is an abstraction over Job).

3rd spec is for the underlying container.