Jobs and CronJobs for batch processing in Kubernetes - Step-by-Step Execution

Process Flow - Jobs and CronJobs for batch processing

Define Job or CronJob YAML

↓

kubectl apply -f file.yaml

↓

Kubernetes creates Job resource

↓

Job creates Pod(s) to run batch task

↓

Pod runs task to completion

↓

Job marks completion or failure

↓

For CronJob: Wait until next schedule

↓

Repeat Job creation on schedule

Shows how defining and applying a Job or CronJob YAML leads Kubernetes to create Pods that run batch tasks once or on a schedule.

Execution Sample

Kubernetes

apiVersion: batch/v1
kind: Job
metadata:
  name: example-job
spec:
  template:
    spec:
      containers:
      - name: batch
        image: busybox
        command: ["/bin/sh", "-c", "echo Hello; sleep 5"]
      restartPolicy: Never

This Job runs a simple batch task that prints 'Hello' and sleeps for 5 seconds, then completes.

Process Table

Step	Action	Resource State	Pod State	Output/Result
1	Apply Job YAML with kubectl	Job resource created	No Pod yet	Job registered in cluster
2	Kubernetes creates Pod for Job	Job active	Pod Pending	Pod scheduled to node
3	Pod starts container	Job active	Pod Running	Container runs command
4	Container executes 'echo Hello'	Job active	Pod Running	Output: Hello
5	Container sleeps 5 seconds	Job active	Pod Running	Waiting...
6	Container finishes command	Job succeeded	Pod Succeeded	Pod completes successfully
7	Job marks completion	Job completed	Pod terminated	Batch task done
8	For CronJob: Wait for next schedule	CronJob active	No Pod	Next Job will start later
9	Exit	No new Pods until schedule	No Pod	Waiting for next run

💡 Job completes when Pod finishes successfully; CronJob waits for next scheduled time to create new Job

Status Tracker

Variable	Start	After Step 2	After Step 4	After Step 6	Final
Job Status	Not created	Active	Active	Succeeded	Completed
Pod Status	None	Pending	Running	Succeeded	Terminated
Output	None	None	"Hello"	None	None

Key Moments - 3 Insights

Why does the Pod start in Pending state before Running?

The Pod is first scheduled to a node (Pending) before the container starts running (Running), as shown in execution_table step 2 and 3.

What happens if the container command fails?

The Job will mark failure and may retry depending on spec; this differs from the successful completion shown in step 6 and 7.

How does CronJob differ from Job in execution?

CronJob creates Jobs on a schedule repeatedly, waiting between runs as shown in steps 8 and 9, unlike a single Job that runs once.

Visual Quiz - 3 Questions

Look at the execution table, what is the Pod state at step 4?

A Pending

B Running

C Succeeded

D Terminated

💡 Hint

Check the 'Pod State' column at step 4 in the execution_table.

At which step does the Job mark completion?

A Step 5

B Step 6

C Step 7

D Step 8

💡 Hint

Look for 'Job marks completion' in the 'Action' column of execution_table.

If the container command took longer to run, which step would be delayed?

A Step 6 Container finishes command

B Step 3 Pod Running

C Step 5 Container sleeps

D Step 4 Container executes command

💡 Hint

Longer command execution affects when the container finishes, shown in step 6.

Concept Snapshot

Jobs run batch tasks once by creating Pods that execute commands to completion.
CronJobs schedule Jobs repeatedly at set times.
Apply YAML with kubectl to create Jobs or CronJobs.
Pods start Pending, then Running, then Succeeded or Failed.
Job status updates track Pod completion.
CronJobs wait between runs to create new Jobs.

Full Transcript

This visual execution shows how Kubernetes Jobs and CronJobs work for batch processing. First, you define a Job or CronJob in YAML and apply it with kubectl. Kubernetes creates a Job resource, which then creates a Pod to run the batch task. The Pod starts in Pending state while scheduled, then moves to Running as the container executes the command. The example command prints 'Hello' and sleeps for 5 seconds. After the container finishes, the Pod status changes to Succeeded and the Job marks completion. For CronJobs, after one Job finishes, Kubernetes waits until the next scheduled time to create a new Job and Pod, repeating the process. This step-by-step flow helps beginners see how batch tasks run once or on a schedule in Kubernetes.

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