Jobs and CronJobs

Not every workload in Kubernetes runs forever. Some tasks start, do their work, and exit. A database migration, a batch report, a nightly data export — these are finite operations. Running them inside a Deployment would be wrong: the Deployment would restart the container every time it completed, treating a successful exit as a failure. Kubernetes needs a different abstraction for this pattern, and that abstraction is the Job.

A Job creates one or more Pods and ensures that a specified number of them successfully terminate. Once the required number of completions is reached, the Job is considered complete. The Pods aren’t restarted. The work is done. This run-to-completion semantic is the fundamental difference between Jobs and Deployments. A Deployment maintains a desired state indefinitely; a Job pursues a desired outcome and then stops.

Why Jobs Matter for the CKAD

The CKAD exam tests Jobs explicitly. You’ll be asked to create Jobs with specific completion counts, set parallelism constraints, and configure failure policies. You’ll also need to create CronJobs — the scheduled variant that spawns a new Job on a cron schedule. These aren’t obscure topics. Batch processing and scheduled automation appear in real clusters constantly, and the exam reflects that reality.

What Jobs Control

A Job exposes several parameters that control execution behavior. Completions defines how many Pods must finish successfully before the Job is done. Parallelism controls how many Pods run concurrently. backoffLimit caps the number of retries before Kubernetes marks the Job as failed. activeDeadlineSeconds sets a hard time limit on the entire Job, regardless of how many retries remain.

The restart policy on a Job’s Pod template must be either Never or OnFailure — never Always. This constraint exists because Always would conflict with the run-to-completion model. If the container keeps restarting indefinitely, the Job can never complete.

CronJobs: Scheduled Job Creation

A CronJob is a controller that creates Jobs on a recurring schedule, defined with standard cron syntax. Every time the schedule fires, the CronJob spawns a new Job, which in turn creates the Pods needed to execute the task. The CronJob itself doesn’t run any workload — it acts as a factory for Jobs.

CronJobs introduce their own set of controls. concurrencyPolicy determines what happens when a new scheduled run fires while a previous Job is still executing: allow both, forbid the new run, or replace the old one. startingDeadlineSeconds defines how long the CronJob has to start a missed run before it gives up. History limits control how many completed and failed Jobs are retained for inspection.

Chapter Structure

The first section covers Job mechanics in depth: creating Jobs imperatively and declaratively, configuring completion modes (NonIndexed and Indexed), setting parallelism, handling failures with backoff limits and deadlines, and cleaning up finished Jobs with TTL controllers.

The second section focuses on CronJobs: cron schedule syntax with common patterns, concurrency policies that prevent overlapping runs, suspension for pausing schedules, and debugging techniques for Jobs that don’t fire when expected.

By the end of this chapter, you’ll be able to create any batch workload the CKAD throws at you — whether it runs once or on a repeating schedule.