Jobs and CronJobs for batch processing in Kubernetes - Mini Project: Build & Apply

Jobs and CronJobs for batch processing

📖 Scenario: You work in a company that needs to run tasks automatically in Kubernetes. Some tasks run once, and some run repeatedly on a schedule. You will create Kubernetes Job and CronJob resources to handle these batch tasks.

🎯 Goal: Learn how to create a Kubernetes Job to run a one-time batch task and a CronJob to run a task on a schedule.

📋 What You'll Learn

Create a Kubernetes Job YAML manifest with exact metadata and spec

Add a CronJob YAML manifest with a schedule and job template

Use the correct container image and command for the batch task

Print the created resource names to confirm creation

💡 Why This Matters

🌍 Real World

Companies use Kubernetes Jobs to run one-time batch tasks like data processing or backups. CronJobs run scheduled tasks like report generation or cleanup jobs automatically.

💼 Career

Knowing how to create and manage Jobs and CronJobs is essential for DevOps engineers and site reliability engineers to automate and maintain batch workloads in Kubernetes.

1

Create a Kubernetes Job manifest

Create a YAML manifest named job.yaml for a Kubernetes Job with these exact details: metadata name batch-job, spec template with a single container named batch-task using image busybox and command ["/bin/sh", "-c", "echo Hello from Job"]. The restart policy must be Never.

Kubernetes

# Write the YAML manifest for the Kubernetes Job here
# Your code here

Hint

Remember to set kind to Job and use the exact container name and command.

2

Create a Kubernetes CronJob manifest

Create a YAML manifest named cronjob.yaml for a Kubernetes CronJob with these exact details: metadata name batch-cronjob, schedule "*/5 * * * *" (every 5 minutes), job template with a single container named cron-task using image busybox and command ["/bin/sh", "-c", "echo Hello from CronJob"]. The restart policy must be OnFailure.

Kubernetes

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

# Write the YAML manifest for the Kubernetes CronJob here
# Your code here

Hint

Use kind: CronJob and set the schedule to run every 5 minutes exactly as shown.

3

Apply the Job and CronJob manifests

Write the exact kubectl commands to apply both job.yaml and cronjob.yaml files to the Kubernetes cluster.

Kubernetes

apiVersion: batch/v1
kind: Job
metadata:
  name: batch-job
spec:
  template:
    spec:
      containers:
      - name: batch-task
        image: busybox
        command: ["/bin/sh", "-c", "echo Hello from Job"]
      restartPolicy: Never
---
apiVersion: batch/v1
kind: CronJob
metadata:
  name: batch-cronjob
spec:
  schedule: "*/5 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: cron-task
            image: busybox
            command: ["/bin/sh", "-c", "echo Hello from CronJob"]
          restartPolicy: OnFailure

# Write the kubectl apply commands below
# Your code here

Hint

Use kubectl apply -f with the exact file names.

4

Print the names of created Job and CronJob

Write the exact kubectl commands to list the names of Jobs and CronJobs in the current namespace.

Kubernetes

apiVersion: batch/v1
kind: Job
metadata:
  name: batch-job
spec:
  template:
    spec:
      containers:
      - name: batch-task
        image: busybox
        command: ["/bin/sh", "-c", "echo Hello from Job"]
      restartPolicy: Never
---
apiVersion: batch/v1
kind: CronJob
metadata:
  name: batch-cronjob
spec:
  schedule: "*/5 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: cron-task
            image: busybox
            command: ["/bin/sh", "-c", "echo Hello from CronJob"]
          restartPolicy: OnFailure

kubectl apply -f job.yaml
kubectl apply -f cronjob.yaml

# Write the kubectl commands to list Job and CronJob names
# Your code here

Hint

Use kubectl get jobs and kubectl get cronjobs with custom columns to show only names.

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