Kubernetes · Orchestration under pressure
How do Jobs and CronJobs work?
Short answer
A Job runs pods until a specified number of successful completions. A CronJob creates Jobs on a schedule, with controls for concurrency, deadlines and history.
Jobs are for finite work: migrations, batch processing, report generation. You can set completions and parallelism to control how many pods run and how many successes are required. A pod that exits zero counts as a success; a non-zero exit is retried until backoffLimit is exhausted.
- backoffLimit caps retries; activeDeadlineSeconds caps total runtime
- CronJob concurrencyPolicy can be Allow, Forbid or Replace
- startingDeadlineSeconds controls how late a missed run may start
- successfulJobsHistoryLimit and failedJobsHistoryLimit control retained Jobs
- Jobs are not services; they usually need no Service unless they expose work
apiVersion: batch/v1
kind: CronJob
metadata:
name: nightly-report
spec:
schedule: "0 2 * * *"
concurrencyPolicy: Forbid
startingDeadlineSeconds: 600
jobTemplate:
spec:
backoffLimit: 3
template:
spec:
restartPolicy: Never
containers:
- name: report
image: registry.example.com/report:1.2.0
args: ["--date", "yesterday"]Scheduled work needs idempotency because retries and overlapping runs happen. Write outputs to durable storage, use unique run identifiers and make the job safe to execute twice. For long jobs, set deadlines so a stuck pod does not block the next schedule forever.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1What happens when a Job pod fails repeatedly?
- 2How do you prevent overlapping CronJob runs?
- 3Why should batch jobs be idempotent?
- 4How do you debug a CronJob that never runs?
Say it in the interview
Jobs run finite work to completion, and CronJobs create Jobs on a schedule. I use completions and parallelism for batch fan-out, and backoffLimit plus deadlines to bound failure. For CronJobs I set a concurrency policy and make the work idempotent, because retries and missed schedules happen. I also check time zones and history limits so old Jobs do not pile up.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Kubernetes mock interview and get scored feedback on depth, clarity and confidence.