Jobs and CronJobs: batch and scheduled workloads

A Deployment's whole design (from lesson 1's controller reconciliation loop) assumes a Pod that should always be running — if it exits, the controller restarts it, treating that exit as a failure to correct. A database migration script that's supposed to run once and exit successfully would just get restarted forever by a Deployment, since "exited" and "failed" look identical to a controller built for long-running processes.

A Job creates a Pod, waits for it to complete successfully, and then considers the work done — no restart on a clean exit, retries on failure up to a configured limit:

backoffLimit caps how many times a failing Pod gets retried before the Job itself is marked failed — a genuine safety net distinguishing "flaky, worth retrying a few times" from "consistently broken, stop trying and alert someone" instead of retrying forever.

A Job can also run multiple Pods to process a batch of work in parallel, rather than just one Pod once:

This fits a queue of independent work items (processing 10 uploaded files, say) where the order between items doesn't matter and several can safely run at the same time — a distinct use case from the single database migration example above, but the same underlying Job object handles both.

A CronJob creates a new Job automatically on a schedule, using the same syntax as Unix cron:

Each scheduled firing creates a fresh Job, which creates a fresh Pod, following exactly the run-to-completion semantics already described — a CronJob is really just "a Job, created repeatedly on a schedule," not a separate execution model.

If a scheduled task takes longer than the interval between runs (a cleanup job scheduled hourly that occasionally takes 90 minutes), multiple instances can end up running concurrently unless explicitly prevented:

Forbid skips starting a new run while one is still in progress; Replace cancels the still-running one and starts fresh instead. Leaving this unset (Allow, the default) permits overlapping runs, which is exactly correct for genuinely independent, order-agnostic tasks and exactly wrong for a task that assumes only one copy of itself is ever running against the same data at once.