Jobs and CronJobs for batch processing in Kubernetes - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is a Kubernetes Job?

A Kubernetes Job runs a task to completion. It creates one or more pods and ensures they finish successfully. Once done, the Job stops.

beginner

What is a CronJob in Kubernetes?

A CronJob runs Jobs on a schedule, like a clock. It creates Jobs repeatedly at specified times, similar to a calendar alarm.

intermediate

How does a Job ensure a task completes successfully?

A Job creates pods and watches them. If a pod fails, the Job starts a new pod until the task finishes successfully.

beginner

What is the key field to set the schedule in a CronJob YAML?

The key field is spec.schedule. It uses cron format like "*/5 * * * *" to run every 5 minutes.

intermediate

What happens if a CronJob's previous Job is still running when the next schedule starts?

By default, Kubernetes may skip starting a new Job if the previous one is still running, to avoid overlap. This behavior can be controlled with concurrencyPolicy.

What does a Kubernetes Job do?

A Manages network traffic

B Runs continuously without stopping

C Schedules tasks repeatedly on a timer

D Runs a task to completion and stops

A Job runs a task and ensures it finishes successfully, then stops.

Which field defines the schedule for a CronJob?

A spec.schedule

B metadata.name

C spec.template

D spec.replicas

The schedule is set in spec.schedule using cron syntax.

What happens if a Job pod fails before completion?

A The pod restarts automatically without Job intervention

B The Job stops immediately

C The Job creates a new pod to retry

D The Job deletes itself

The Job controller creates new pods to retry until success.

What is the default behavior if a CronJob's previous Job is still running at the next schedule?

A Skip starting a new Job

B Start a new Job anyway

C Delete the old Job

D Send an alert

By default, Kubernetes skips starting a new Job to avoid overlap.

Which Kubernetes resource would you use to run a task every day at midnight?

A Job

B CronJob

C Deployment

D Service

CronJob runs Jobs on a schedule, such as daily at midnight.

Explain the difference between a Kubernetes Job and a CronJob.

Think about one-time tasks versus scheduled repeated tasks.

Describe how Kubernetes handles a Job pod failure during batch processing.

Focus on Job's retry mechanism.

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