Chapter 18: Batch processing with Jobs and CronJobs

Introduction

The introduction distinguishes continuously running pods from finite workloads and explains when to use a Job or a CronJob.

• Finite versus continuous workloads: Explain why pods managed by Deployments, StatefulSets, or DaemonSets are unsuitable for a task that should finish, and identify a Job as the resource for a finite workload.
  Why it matters: Choosing a Job lets a task finish instead of treating its termination as something to restart.
• Jobs and scheduled tasks: Distinguish a Job that runs its pods immediately from a CronJob that schedules a Job for a future time or regular intervals.
  Why it matters: The distinction tells you which resource to choose when a finite task must run later or recur.

Key terms: finite workload, Job resource, Kubelet, Job, CronJob

18.1 Running tasks with the Job resource

This section contrasts finite tasks with continuously running pods and explains why a Job is preferable to managing a one-off pod yourself.

• Finite versus continuous workloads: Distinguish a task that should finish successfully and exit from a workload whose pods are kept running continuously. Describe how the OnFailure restart policy allowed the quiz-data-importer Pod to finish without restarting its successful container.
  Why it matters: It clarifies why a task such as database initialization needs different behavior from an application kept running by a Deployment.
• Job versus standalone pod: Explain why creating a one-off pod directly is insufficient when it might be deleted prematurely or its node might fail, and why the section recommends creating a Job instead.
  Why it matters: A Job avoids relying on a person to keep a potentially long-running task on track after its pod is lost.

Key terms: OnFailure restart policy, quiz-data-importer Pod, Deployment, Job object, pod, node

18.1.1 Introducing the Job resource

Introduces Jobs as workloads that finish after their pods succeed, then shows how to create, inspect, suspend, resume, and delete them.

• Job completion model: Explain how a Job differs from a Deployment and when a Job is complete.
  Why it matters: Completion, rather than continuous operation, is the defining purpose of a Job.
• Job pod template requirements: Describe what the example Job specifies for its pod and why its restart policy must be explicit.
  Why it matters: The template defines the work, while a compatible restart policy allows the Job's pod to finish.
• Job status and pod inspection: Describe how to check a Job's progress and inspect its pods and logs.
  Why it matters: These checks let you verify completion and investigate what the Job's containers did.
• Job suspension and resumption: Explain how suspension affects pod creation or running pods, and how a Job resumes.
  Why it matters: Suspension lets you control when a Job starts or interrupt one that is already running.
• Job deletion and pod ownership: Distinguish normal Job deletion from deletion that preserves its pods.
  Why it matters: The deletion choice determines whether the pods disappear with their Job or remain for you to manage.
• Finished Job time to live: Explain how automatic Job cleanup is configured and why it can hinder failure investigation.
  Why it matters: Automatic cleanup saves manual work, but the retention period must leave enough time to inspect failures.

Key terms: Job, pod, completions, Pod template, init container, restartPolicy, OnFailure, Never, STATUS, DURATION

18.1.2 Running a task multiple times

This section explains how Job completions and parallelism control repeated task execution, then shows how to observe a five-completion Job running at most two pods at once.

• Job completion and parallelism settings: Explain what completions and parallelism specify, including what happens when neither or only one is set.
  Why it matters: These two settings let you distinguish how much successful work a Job requires from how much it runs concurrently.
• Parallel Job pod progression: Trace how the Job controller runs a task five successful times with completions set to 5 and parallelism set to 2, and explain what happens if parallelism exceeds completions.
  Why it matters: The Job can complete several runs without starting every pod at once.
• Observing repeated Job execution: Describe how the example Job is created and checked, and what the pod and Job listings show about its progress.
  Why it matters: The listings provide a way to check that the configured concurrency and success target match what the Job actually did.

Key terms: Job, completions, parallelism, Job controller, pods, kubectl apply, Running, Completed, RESTARTS

18.1.3 Understanding how Job failures are handled

Explains how Kubernetes retries failed Job tasks and how retry limits, deadlines, and custom policies can cause a Job to fail.

• Pod and Job failure handling: Distinguish how a Job handles a failed container when its pod's restartPolicy is OnFailure versus Never.
  Why it matters: The restart policy determines whether a failed attempt is retried inside the existing pod or in a replacement pod.
• Job retry backoff limit: Explain when repeated failures cause the Job controller to give up and what happens to the Job's pods afterward.
  Why it matters: A Job does not keep retrying forever when its task repeatedly fails.
• Whole Job completion deadline: Explain how activeDeadlineSeconds can cause a Job to fail even when its pods could eventually complete.
  Why it matters: A deadline must allow enough time for the entire Job, including sequential completions.
• Custom pod failure rules: Describe the kinds of failure decisions a Job's podFailurePolicy can specify instead of relying only on default handling.
  Why it matters: Custom rules let a Job treat selected failures differently from its default retry behavior.

Key terms: restartPolicy, OnFailure, Never, Kubelet, Job controller, backoff limit, spec.backoffLimit, activeDeadlineSeconds, completions, parallelism

18.1.4 Parameterizing pods in a Job

This section explains how to give pods distinct portions of a batch task, contrasting separate NonIndexed Jobs with one Indexed Job and showing how a completion index can select simple or complex inputs.

• NonIndexed pod parameter limits: Explain why a NonIndexed Job cannot give each of its pods a different month to process, and describe the separate-Job workaround.
  Why it matters: It explains why the twelve-month example needs twelve Jobs unless you switch completion modes.
• Indexed Job completion semantics: Describe how an Indexed Job distinguishes its pods and when the Job is considered complete, using the twelve-month example.
  Why it matters: One Job can track completion of all twelve distinct portions without managing twelve Job objects.
• Completion index as workload input: Explain how the aggregation script obtains its pod’s index and turns it into a month, including the annotation alternative.
  Why it matters: The index only divides the work correctly if the application interprets it as the right input.
• Init container input preparation: Explain how an indexed Job can process many different input files without changing a main container that expects one fixed filename.
  Why it matters: It extends indexed processing to existing applications whose inputs are files rather than numbers.

Key terms: NonIndexed, Pod template, MONTH, Indexed, completion index, completions, parallelism, JOB_COMPLETION_INDEX, batch.kubernetes.io/job-completion-index, Downward API

18.1.5 Running Jobs with a work queue

This section shows how Jobs can process a container-managed work queue, contrasts coarse and fine parallel processing, and explains why a completed Job does not handle items added later.

• Work queue responsibility: Explain that a Job can get work dynamically from a queue, but Kubernetes does not provide or inspect that queue; the containers must implement the queue and retrieve its items.
  Why it matters: It clarifies which part Kubernetes runs and which part your application must implement.
• Coarse parallel queue processing: Describe how coarse parallel processing assigns one queue item to each pod and how the example uses completions and parallelism to control total and simultaneous pod runs.
  Why it matters: It connects the Job's pod counts to the number of queue items processed.
• Fine parallel queue processing: Trace how a fine-processing pod repeatedly takes queue items until none remain, and explain why the example omits completions and allows other active pods to finish when one succeeds.
  Why it matters: It explains why the fine-processing Job can drain a queue without requiring one pod completion per item.
• Completed Job queue limitation: Explain why adding an item after a queue-processing Job completes does not cause another pod to process it, and distinguish a Deployment for continuous workers from a CronJob for periodic runs.
  Why it matters: It helps you choose a workload that matches whether queue processing should end, continue, or recur on a schedule.

Key terms: Job, work queue, work items, containers, coarse parallel processing, completions, parallelism, work item, fine parallel processing, Job controller

18.1.6 Communication between Job’s Pods

This section shows how pods in an Indexed Job can find and communicate with specific peers through a headless Service and DNS.

• Indexed Job service configuration: Describe how to configure a Job and headless Service so the Job’s pods can find one another: use Indexed completion mode, select the Job’s pods with the Service, and set the pods’ subdomain to the Service name.
  Why it matters: These settings let Job pods address particular peers rather than an arbitrary pod.
• Predictable peer DNS addresses: Explain how a Job pod can address a specific peer through DNS without looking up that peer’s randomly assigned pod name or IP address.
  Why it matters: Predictable DNS addresses let a pod contact the peer it needs without discovering random pod names.

Key terms: Indexed, headless Service, clusterIP, label selector, job-name, subdomain, DNS, completions, comm-demo-0.demo-service, Kubernetes API server

18.1.7 Sidecar containers in Job pods

Explains why an ordinary sidecar can prevent a Job from completing and how a native sidecar lets the Job finish.

• Ordinary sidecar completion problem: Explain why putting a long-running sidecar in a Job Pod’s spec.containers list prevents the Pod and Job from completing.
  Why it matters: A finished batch task can otherwise leave its Job running indefinitely.
• Native sidecar Job placement: Describe where to define a Job Pod’s sidecar so that the Pod and Job can complete when the main task finishes.
  Why it matters: The correct placement lets a Job use a sidecar without losing its completion behavior.

Key terms: sidecar containers, spec.containers, NotReady, initContainers, sidecar container, Completed

18.2 Scheduling Jobs with CronJobs

This section explains why scheduled tasks need a CronJob and how a CronJob creates Jobs that then create pods.

• Job timing limitation: Distinguish a Job that starts immediately or is later unsuspended from a task configured to run at a specific time.
  Why it matters: This explains why a CronJob is needed when a task must run on a schedule.
• CronJob scheduling and pod creation: Trace how a CronJob uses its schedule and Job template to create Jobs, and how those Jobs lead to pods.
  Why it matters: It separates the CronJob’s role in scheduling Jobs from the Job’s role in creating pods.

Key terms: Job, suspended state, CronJob, CronJob object, Job template, schedule, CronJob controller, Job controller

18.2.1 Creating a CronJob

Shows how to create a CronJob from a manifest and inspect the Jobs, pods, status, and events it produces.

• CronJob schedule and Job template: Explain that a CronJob wraps a Job template with a schedule, and describe how to create the CronJob from its manifest.
  Why it matters: The schedule and Job template are the two pieces you need to recognize when reading a CronJob manifest.
• Finding CronJob Jobs and pods: Describe how to find the Jobs and pods associated with a CronJob, including why labels are added to both templates.
  Why it matters: Template labels make it practical to find both the Jobs a CronJob creates and the pods those Jobs run.
• CronJob run status and events: Describe what the CronJob listing, detailed status, and events reveal about scheduled runs, and how to check whether the last run succeeded.
  Why it matters: Checking beyond the brief listing helps distinguish a scheduled run from a successful one.

Key terms: CronJob, schedule, jobTemplate, Job, CronJob controller, Job template, Pod template, label selector, ACTIVE, LAST SCHEDULE

18.2.2 Configuring the schedule

Explains how to read a CronJob schedule, including crontab fields, day-matching behavior, shorthand schedules, and time zones.

• Five-field crontab schedule: Describe the five schedule fields in order and explain how their values determine when a CronJob is triggered.
  Why it matters: Reading the fields lets you tell when a CronJob is scheduled to create a Job.
• Day field matching exception: Explain why specifying both a day of the month and a day of the week can trigger a CronJob more often than expected.
  Why it matters: This exception prevents a schedule from unexpectedly running on many more days than intended.
• Schedule shorthand values: Describe how special schedule values replace simple five-field schedules and give examples of when they trigger.
  Why it matters: Shortcuts make common schedules easier to express.
• CronJob scheduling time zone: Explain which time zone a CronJob uses by default and how to specify a different one.
  Why it matters: An explicit time zone helps keep scheduled runs aligned with the time you intend.

Key terms: schedule, crontab format, minute, hour, day of the month, month, Day of month, Day of week, @hourly, @daily

18.2.3 Suspending and resuming a CronJob

Explains how to suspend and resume a CronJob and what happens to Jobs when it is suspended.

• CronJob suspension and resumption: Explain that a CronJob can be suspended with kubectl patch and resumed later. Describe how suspension affects new and already-running Jobs, and note that a CronJob can be created suspended.
  Why it matters: Suspension pauses future scheduled work without interrupting Jobs that have already started.

Key terms: CronJob, kubectl patch, suspended, Job

18.2.4 Automatically removing finished Jobs

Explains why a CronJob retains only some finished Jobs and how to change its history limits.

• CronJob finished Job retention: Explain that the CronJob controller deletes completed Jobs according to separate history limits for successful and failed Jobs, and that pods belonging to retained Jobs remain available for log viewing.
  Why it matters: It explains why older Jobs disappear from a listing while logs for retained Jobs remain accessible.

Key terms: CronJob controller, successfulJobsHistoryLimit, failedJobsHistoryLimit, Job, pods

18.2.5 Setting a start deadline

Explains how a CronJob start deadline limits late Job creation and prevents a backlog of missed Jobs after controller downtime.

• CronJob start deadline behavior: Explain why a CronJob might create a Job late and how startingDeadlineSeconds limits that delay. Describe what happens when the controller misses the stated 30-second deadline.
  Why it matters: A deadline prevents a time-sensitive Job from starting when it is already too late to be useful.
• Missed Jobs after downtime: Describe what an offline CronJob controller does when it returns without a start deadline, including the limit on missed Jobs and how a deadline helps.
  Why it matters: A deadline can avoid a burst of stale Jobs when the controller returns after downtime.

Key terms: startingDeadlineSeconds, CronJob controller, MissSchedule event, TooManyMissedTimes event, missing jobs

18.2.6 Handling Job concurrency

Explains that CronJob runs can overlap by default and that the CronJob spec provides a concurrencyPolicy setting to change this behavior.

• CronJob run concurrency: Explain what happens when a scheduled Job takes longer than the interval before the next run, and identify the CronJob setting that changes the default behavior.
  Why it matters: A scheduled task can have overlapping runs unless you configure its concurrency behavior.

Key terms: CronJob controller, Job, ACTIVE column, concurrencyPolicy

18.2.7 Deleting a CronJob and its Jobs

This section explains how deleting a CronJob affects its Jobs and pods, and how to preserve them when removing the CronJob.

• CronJob deletion and preservation: Distinguish suspending a CronJob from deleting it, and explain what happens to its Jobs and pods when it is deleted normally or with --cascade=orphan.
  Why it matters: The deletion choice determines whether existing work is stopped or allowed to finish.

Key terms: CronJob, Job, pods, --cascade=orphan, suspend

18.3 Summary

Summarizes how Jobs run tasks to completion, how their pods can divide and coordinate work, and how CronJobs schedule Jobs.