Jobs & CronJobs
A Deployment keeps a number of Pods up; a Job counts how many have succeeded. Hand work that has to finish — a nightly reconciliation, a data migration — to a Deployment and every finished Pod looks like an empty slot, so the same work starts over forever. A Job stops creating Pods once the declared number of completions is reached, and a CronJob stamps out that Job on a schedule.
01Jobs & CronJobs
Concept at a GlanceA web server has to stay up, but some work — a reconciliation, a data migration — has to finish. Hand that to a Deployment and things go wrong.
The Pod that finished its work reads as an empty slot. One was declared and one is missing, so the same work starts from the top.
A Job counts successes rather than Pods that are up. Six finishes mean done, and it runs two at a time.
The Job controller creates two Pods. The number that run at once is parallelism.
One of them finishes. The completion count goes up by one and the next Pod immediately takes the free slot.
Finished Pods are not deleted — you need their logs. What piles up is cleared by ttlSecondsAfterFinished.
One Pod ends in an error. The Job does not give that share up; it creates a new Pod and tries again.
The gap before each retry doubles. Once failures pass backoffLimit (6 by default), the Job itself fails.
The sixth completion lands. The Job is marked Complete and creates no further Pods.
To run this every day at three in the morning, put a CronJob on top. What a CronJob creates is not a Pod but a Job.
Past runs are kept as a record. Only so many are held and the oldest Job is dropped first, so yesterday's is about as far back as you can look.
02 Understand It Simply
For EveryoneA Deployment holds a count of running pods; a Job counts successful completions. Treat finishing work as a count and every pod that finishes leaves a gap that gets filled again.
A Job runs on two numbers: completions (how many successes to collect) and parallelism (how many Pods run at once).
Each successful Pod raises the count and the free slot is taken by the next Pod; once the count is full the Job is marked Complete and no more Pods are made.
A Pod that fails is retried with a new Pod at doubling intervals, and if failures pass backoffLimit (6 by default) the Job itself fails.
Job Pods may only use restartPolicy Never or OnFailure — Always contradicts work that ends and is rejected outright.
Finished Pods are not deleted, which is what lets you read their logs, and ttlSecondsAfterFinished clears out what accumulates.
A CronJob creates Jobs rather than Pods (CronJob → Job → Pod).
What happens when the previous run has not finished is set by concurrencyPolicy (Allow, Forbid, Replace), and past runs are kept only up to successfulJobsHistoryLimit (3 by default).
The scheduled time is not guaranteed exactly — startingDeadlineSeconds decides how late a missed run may still start.
- –Moving batch and migration work off Deployments and onto Jobs
- –splitting work with completions and parallelism
- –setting retry limits and failure criteria
- –and picking a concurrency policy when a recurring task becomes a CronJob
03 Frequently Asked Questions
FAQWhat is Jobs & CronJobs?+
A Deployment keeps a number of Pods up; a Job counts how many have succeeded. Hand work that has to finish — a nightly reconciliation, a data migration — to a Deployment and every finished Pod looks like an empty slot, so the same work starts over forever. A Job stops creating Pods once the declared number of completions is reached, and a CronJob stamps out that Job on a schedule.
Where is Jobs & CronJobs used?+
Moving batch and migration work off Deployments and onto Jobs, splitting work with completions and parallelism, setting retry limits and failure criteria, and picking a concurrency policy when a recurring task becomes a CronJob.
What's a simple analogy for Jobs & CronJobs?+
A Deployment holds a count of running pods; a Job counts successful completions. Treat finishing work as a count and every pod that finishes leaves a gap that gets filled again.