How to use Jobs In Kubernetes

Introduction

Jobs In Kubernetes is like other resources but allows you to run a pod whose container isn’t restarted when the process running inside finishes successfully. Once it does, the pod is considered complete. Job resource is controlled by a job controller, which supervises pods for carrying out certain tasks.

How does it work?

Jobs are managed by a job controller and the controller is non terminated loop that regulates the state of the system. Whenever the job controller sees a new task it makes sure that the kubelet on the set of nodes is running the right number of pods to get the work done. In the event of a node failure, the pods on that node that are managed by a Job will be rescheduled to other nodes the way ReplicaSet pods are.

Types of job

• Run to completion
• Cron Job

We will be looking at the Run to completion job and Cron job.

apiVersion: batch/v1
kind: Job
metadata:
  name: helloworld
spec:
  template: #template will be use for creating pod
    spec:
      containers:
         - name: busybox #name of the container 
           image: busybox
           command: ["echo","k8s"]  
      restartPolicy: Never

Jobs are part of the batch API group and v1 API version. The YAML defines a resource of type Job that will run the image busybox. you can specify what Kubernetes should do when the processes running in the container finish. This is done through the restartPolicy pod spec property, which defaults to Always. Job pods can’t use the default policy, because they’re not meant to run indefinitely. Therefore, you need to explicitly set the restart policy to either OnFailure or Never.

Run Job in sequence

Job In Kubernetes To run a job more than once, we can set completions .it will run the job one after another in a sequence. we just need to add completions and the value.

#In completion 
#job we create one after one  and it will do so on 
#In my example has written completions: 2  that means it will create 2 pod on after another
apiVersion: batch/v1
kind: Job
metadata:
  name: helloworld
spec:
  completions: 2 #one after another 
  template: #template will be use for creating pod
    spec:
      containers:
         - name: busybox #name of the container 
           image: busybox
           command: ["echo","k8s"]  
      restartPolicy: Never

Run job in parallel

We can also set the job to run parallel instead of in sequence. we can specify how many pods are allowed to run in parallel with parallel

apiVersion: batch/v1
kind: Job
metadata:
  name: helloworld
spec:
  completions: 4 #one after another 
  parallelism: 2 # two pod can run in parallel
  template: #template will be use for creating pod
    spec:
      containers:
         - name: busybox #name of the container 
           image: busybox
           command: ["echo","k8s"]  
      restartPolicy: Never

ActiveDeadlineSeconds

We can also limit the time allowed for a job pod for example How long should the Job wait for a pod to finish? What if the pod gets stuck and can’t finish at all. For that, we can use activeDeadlineSeconds property. If the pod runs longer than that, the system will try to terminate it and will mark the job as failed.

apiVersion: batch/v1
kind: Job
metadata:
  name: helloworld
spec:
  activeDeadlineSeconds: 10 #if this job take more than sec then terminate the pods 
  template: #template will be use for creating pod
    spec:
      containers:
         - name: busybox #name of the container 
           image: busybox
           command: ["sleep","20"]  
      restartPolicy: Never

backOffLimit 

We can use backOffLimit when we want we want to a job to be considered a failure after some amount of retries due to a logical error. Use .spec.backoffLimit to specify the number of retries before considering a Job as failed. The back-off limit is set by default to 6.

apiVersion: batch/v1
kind: Job
metadata:
  name: helloworld
spec:
  backoffLimit: 2
  template: #template will be use for creating pod
    spec:
      containers:
         - name: busybox #name of the container 
           image: busybox  #image is being used from docker 
           command: ["ls","/knoldus"]  #making failed my container as there is no folder KNOLDUS in my container
      restartPolicy: Never

Cron Job

Let’s take an example you want to take a backup of your database every night. In this kind of scenario, you can schedule your job using Cron Job. Let’s see the example.

 apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: helloworld-cron
spec:
  schedule: "* * * * *"  #Everymin
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: busybox
            image: busybox
            command: ["echo", "Hello Kubernetes!!!"]
          restartPolicy: Never

Kind is changed to CronJob and A CronJob creates Job resources from the jobTemplate property configured in the CronJob spec, we need to clean cronjob manually when we delete cronjob pod is left behind. After applying the above example we have to wait for one minute. we can use add successfulJobsHistoryLimit it can help us to see successful cron. similarly, we can set FailedJobsHistoryLimit to see the list of failed pods.

Conclusion

Jobs just run to completion which means it spins up some pods and ensures that a specific task has been done by the number of pods and then terminated. Similarly, we have Cronjob which can be used to schedule jobs. In this blog, we have tried to cover a basic aspect of the job .For more info you can always refer to : https://kubernetes.io/docs/