Jobs run pods to completion; CronJobs schedule Jobs. Reliability comes from tuning retries, parallelism, deadlines, and concurrency.

Job knobs

spec: completions: 5 # run to 5 successful pods parallelism: 2 # 2 at a time backoffLimit: 4 # retries before marking failed activeDeadlineSeconds: 600 # hard time cap ttlSecondsAfterFinished: 3600 # auto-clean finished jobs

CronJob concurrency

concurrencyPolicy: Forbid # don't start a new run if the last is still going # (Allow / Forbid / Replace) startingDeadlineSeconds: 100 # skip missed runs older than this successfulJobsHistoryLimit: 3

Reliability concerns

Make jobs idempotent (they can re-run on retry/restart), set deadlines so a hung job doesn't run forever, use ttlSecondsAfterFinished to avoid pile-up, and handle the at-least-once nature (a job pod can run more than once).

Gotcha: Default concurrencyPolicy: Allow can overlap runs if a job runs longer than its schedule interval — pile-ups and double-processing. Use Forbid or Replace for non-idempotent work, and design jobs to be idempotent regardless.

Interview tip: Emphasize idempotency (Kubernetes gives at-least-once, a pod may re-run), concurrencyPolicy to prevent overlap, and activeDeadlineSeconds/ttlSecondsAfterFinished for hygiene. For complex DAGs of jobs, mention Argo Workflows. These details separate "I wrote a CronJob" from "I run reliable batch."