Jobs and CronJobs for batch processing in Kubernetes - Commands & Configuration

Introduction

Sometimes you need to run tasks that do a job once or on a schedule, like sending reports or cleaning up files. Kubernetes Jobs and CronJobs help you run these tasks reliably without keeping them running all the time.

When you want to run a task once and make sure it finishes successfully, like a database backup.

When you need to run a task repeatedly on a schedule, like sending daily emails.

When you want to run batch jobs that process data and then stop.

When you want Kubernetes to retry a task if it fails until it succeeds.

When you want to automate maintenance tasks without manual intervention.

Config File - job-cronjob.yaml

job-cronjob.yaml

apiVersion: batch/v1
kind: Job
metadata:
  name: example-job
spec:
  template:
    spec:
      containers:
      - name: example
        image: busybox
        command: ["/bin/sh", "-c", "echo Hello from Job; sleep 5"]
      restartPolicy: Never
  backoffLimit: 3
---
apiVersion: batch/v1
kind: CronJob
metadata:
  name: example-cronjob
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: example
            image: busybox
            command: ["/bin/sh", "-c", "date; echo Hello from CronJob"]
          restartPolicy: Never

This file defines two Kubernetes resources:

• Job: Runs a simple task once that prints a message and sleeps for 5 seconds. It will retry up to 3 times if it fails.
• CronJob: Runs a task every minute that prints the current date and a message. It uses a cron schedule format.
• restartPolicy: Never means containers won't restart automatically on failure; Kubernetes manages retries.

Commands

This command creates the Job and CronJob resources in Kubernetes from the configuration file.

Terminal

kubectl apply -f job-cronjob.yaml

Expected Output

job.batch/example-job created

cronjob.batch/example-cronjob created

This command lists all Jobs to check if the example job has started or completed.

Terminal

kubectl get jobs

Expected Output

NAME          COMPLETIONS   DURATION   AGE

example-job   1/1           5s         10s

This command lists all CronJobs to verify the example CronJob is scheduled correctly.

Terminal

kubectl get cronjobs

Expected Output

NAME              SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE

example-cronjob   */1 * * * *   False     0        <none>          10s

This command watches pods to see the Job and CronJob create pods when they run their tasks.

Terminal

kubectl get pods --watch

Expected Output

NAME                         READY   STATUS      RESTARTS   AGE

example-job-abcde             0/1     Completed   0          15s

example-cronjob-xyz12         0/1     Completed   0          1s

→

--watch - Keeps the command running to show live updates of pod status

Key Concept

Jobs run tasks once and ensure completion; CronJobs run tasks on a schedule using cron syntax.

Common Mistakes

Setting restartPolicy to Always in Job or CronJob pods

This causes pods to restart endlessly, which is not suitable for batch jobs that should finish after running once.

Always set restartPolicy to Never or OnFailure for Jobs and CronJobs.

Not specifying backoffLimit in Job spec

Without backoffLimit, Kubernetes retries failed jobs indefinitely, which can cause resource waste.

Set backoffLimit to a reasonable number like 3 to limit retries.

Using wrong cron schedule format in CronJob

Incorrect cron syntax causes the CronJob not to run as expected or fail to create.

Use standard cron format with five fields: minute hour day month weekday.

Summary

Use kubectl apply to create Jobs and CronJobs from YAML files.

Check Jobs with kubectl get jobs and CronJobs with kubectl get cronjobs.

Watch pods to see batch tasks run and complete using kubectl get pods --watch.

Practice

1. What is the main difference between a Kubernetes Job and a CronJob?

easy

A. Job runs tasks repeatedly; CronJob runs a task once.

B. Job automatically restarts pods; CronJob does not.

C. Job is for long-running services; CronJob is for batch tasks.

D. Job runs a task once; CronJob runs tasks repeatedly on a schedule.

Solution

1. Step 1: Understand the purpose of a Job

   A Kubernetes Job runs a batch task once and completes when the task finishes.

2. Step 2: Understand the purpose of a CronJob

   A CronJob schedules Jobs to run repeatedly at specified times, like a clock.

3. Final Answer:

   Job runs a task once; CronJob runs tasks repeatedly on a schedule. -> Option D

4. Quick Check:

   Job = one-time, CronJob = scheduled repeat [OK]

Hint: Jobs run once; CronJobs run on a schedule [OK]

Common Mistakes:

• Confusing Job as repeating task
• Thinking CronJob runs only once
• Mixing up Job with long-running services

2. Which of the following is the correct minimal YAML snippet to define a Kubernetes Job?

easy

A. apiVersion: batch/v1
kind: Job
metadata:
name: example-job
spec:
template:
spec:
containers:
- name: task
image: busybox
command: ["echo", "Hello"]
restartPolicy: Never

B. apiVersion: batch/v1
kind: Job
metadata:
name: example-job
spec:
containers:
- name: task
image: busybox
command: ["echo", "Hello"]
restartPolicy: Always

C. apiVersion: batch/v1
kind: Job
metadata:
name: example-job
spec:
template:
containers:
- name: task
image: busybox
command: ["echo", "Hello"]
restartPolicy: Always

D. apiVersion: batch/v1
kind: Job
metadata:
name: example-job
spec:
template:
spec:
containers:
- name: task
image: busybox
command: ["echo", "Hello"]
restartPolicy: Always

Solution

1. Step 1: Check Job YAML structure

   A Job spec requires a template with a pod spec inside it, including containers and restartPolicy.

2. Step 2: Validate restartPolicy and container placement

   Restart policy must be Never or OnFailure for Jobs, and containers must be under spec.template.spec.

3. Final Answer:

   Correct structure with template.spec.containers and restartPolicy: Never -> Option A

4. Quick Check:

   Job YAML needs template.spec with restartPolicy Never [OK]

Hint: Job YAML needs template.spec and restartPolicy Never [OK]

Common Mistakes:

• Placing containers directly under spec
• Using restartPolicy Always in Job
• Missing template.spec nesting

3. Given this CronJob YAML snippet, what will happen?

apiVersion: batch/v1
kind: CronJob
metadata:
  name: hello-cron
spec:
  schedule: "*/5 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            command: ["echo", "Hello World"]
          restartPolicy: OnFailure

medium

A. The job runs every 5 minutes but never prints anything.

B. The job runs once and never repeats.

C. The job runs every 5 minutes, printing "Hello World" once each time.

D. The job runs continuously without stopping.

Solution

1. Step 1: Understand the schedule field

   The schedule "*/5 * * * *" means run every 5 minutes.

2. Step 2: Understand the jobTemplate behavior

   Each scheduled time creates a Job that runs the container once, printing "Hello World".

3. Final Answer:

   The job runs every 5 minutes, printing "Hello World" once each time. -> Option C

4. Quick Check:

   CronJob schedule "*/5 * * * *" = every 5 minutes [OK]

Hint: CronJob schedule "*/5 * * * *" means every 5 minutes [OK]

Common Mistakes:

• Thinking CronJob runs only once
• Assuming continuous running container
• Ignoring the command output

4. You created a CronJob but notice it never runs. Which YAML mistake could cause this?

medium

A. Missing schedule field in the CronJob spec.

B. Using restartPolicy: Always in the Job template.

C. Setting image to a valid container image.

D. Defining command as an array.

Solution

1. Step 1: Check required CronJob fields

   The schedule field is mandatory to tell when to run the job.

2. Step 2: Identify impact of missing schedule

   Without schedule, the CronJob controller cannot trigger jobs, so none run.

3. Final Answer:

   Missing schedule field prevents CronJob from running. -> Option A

4. Quick Check:

   CronJob needs schedule to run [OK]

Hint: CronJob must have schedule field to run [OK]

Common Mistakes:

• Using restartPolicy Always (allowed but not cause no run)
• Thinking image or command cause no run
• Ignoring missing schedule field

5. You want to run a cleanup task every day at midnight using a CronJob. Which schedule string correctly sets this time?

hard

A. "0 * * * 0"

B. "0 0 * * *"

C. "* * 0 * *"

D. "0 12 * * *"

Solution

1. Step 1: Understand cron schedule format

   The format is: minute hour day month weekday.

2. Step 2: Interpret each option

   "0 0 * * *": "0 0 * * *" means at minute 0, hour 0 (midnight) every day.
   "* * 0 * *": "* * 0 * *" is invalid because day 0 does not exist.
   "0 * * * 0": "0 * * * 0" means every hour at minute 0 on Sundays only.
   "0 12 * * *": "0 12 * * *" means noon every day.

3. Final Answer:

   "0 0 * * *" runs daily at midnight. -> Option B

4. Quick Check:

   Midnight daily = "0 0 * * *" [OK]

Hint: Midnight daily cron is "0 0 * * *" [OK]

Common Mistakes:

• Using day 0 which is invalid
• Confusing hour 12 (noon) with midnight
• Misplacing fields in schedule string