Jobs & CronJobs

Jobs: run-to-completion, not run-forever

Every workload you've built so far — Deployments, the ReplicaSets behind them — assumes pods run forever. If one exits, that's treated as a problem, and it gets restarted. A Job flips that assumption: its pods are supposed to finish, and a successful exit is the goal, not a failure.

A Job tracks completions (how many successful pod runs it needs) and parallelism (how many can run at once). If a pod's container exits non-zero, the Job retries a new pod, up to backoffLimit — cross that, and the Job gives up and marks itself Failed, visible in kubectl get jobs and kubectl describe job.

This is the same exit-code/Events diagnosis muscle from Module 2's CrashLoopBackOff lab — the difference is just what "the pod exited" means for the controller watching it: a Deployment sees it as drift to correct forever; a Job sees it as one attempt, counted against a limit.

CronJobs: a Job template on a schedule

A CronJob doesn't run anything itself — it creates a new Job from its template on a schedule, using standard cron syntax (minute hour day-of-month month day-of-week, e.g. */5 * * * * for every 5 minutes).

Linux aside: cron is the traditional Unix/Linux job scheduler — a daemon that reads schedule files and runs commands at the times they specify. Kubernetes didn't invent this syntax; it deliberately reused the one generations of Linux admins already know, instead of designing a new scheduling language.

Each firing creates a fresh Job (and fresh pods) — nothing persists between runs unless you explicitly give it somewhere to write (a volume, an external store). concurrencyPolicy controls what happens if a run is still going when the next one is due: Allow (both run), Forbid (skip the new one), or Replace (kill the old one first).

The infrastructure analogy

A Job is your traditional one-off batch script or CI job run — something with a defined "done." A CronJob is literally what it sounds like: cron, but the "box" it runs on is created fresh for every single run instead of being a long-lived machine you SSH into and schedule things on. No drift between runs, because there's no persistent machine to drift.

In the lab, you'll diagnose a Job that keeps failing, then verify a CronJob you create actually fires on schedule — not just that you wrote the YAML correctly, but that the cluster really ran it.