Run-to-Completion Workloads
Deployments keep Pods running forever; that is wrong for batch work like a database migration, a report generation script, or a one-off data import. A Job creates one or more Pods and tracks them until a specified number complete successfully, then stops -- it does not restart Pods that exit with success.
Cricket analogy: A Deployment is like a permanent XI that stays on the field indefinitely; a Job is like calling in a substitute for a single specific task, such as a fitness test, that runs once, completes, and doesn't get repeated once done.
A Basic Job
apiVersion: batch/v1
kind: Job
metadata:
name: db-migration
spec:
completions: 1
backoffLimit: 3
activeDeadlineSeconds: 300
template:
spec:
restartPolicy: Never
containers:
- name: migrate
image: myapp/migrator:1.4
command: ["./migrate", "up"]restartPolicy must be Never or OnFailure for Job Pods (Always is not allowed). backoffLimit caps how many times the Job retries a failing Pod before marking the Job as failed. activeDeadlineSeconds is an overall timeout for the whole Job.
Cricket analogy: restartPolicy Never or OnFailure is like deciding whether a dismissed batsman comes back in (never for a completed innings task); backoffLimit caps how many no-balls a bowler gets before being taken off, and activeDeadlineSeconds is the overall match time limit.
Parallel Jobs
Setting completions and parallelism lets a Job fan out work across multiple Pods concurrently -- useful for embarrassingly parallel batch processing, such as processing a queue of independent work items.
Cricket analogy: Setting completions and parallelism is like fielding multiple net sessions simultaneously across several nets, each bowler working through their own set of deliveries in parallel rather than one bowler doing all the overs sequentially.
apiVersion: batch/v1
kind: Job
metadata:
name: batch-process
spec:
completions: 10
parallelism: 3
backoffLimit: 5
template:
spec:
restartPolicy: OnFailure
containers:
- name: worker
image: myapp/worker:2.0CronJobs: Scheduling Jobs on a Timer
A CronJob creates a new Job on a recurring schedule expressed using standard five-field cron syntax (minute hour day-of-month month day-of-week). It is ideal for nightly backups, periodic report generation, or scheduled cleanup tasks.
Cricket analogy: A CronJob is like a scheduled net practice every Monday at 6am, automatically creating a fresh training session (Job) on that recurring schedule without anyone manually calling the players each week.
apiVersion: batch/v1
kind: CronJob
metadata:
name: nightly-backup
spec:
schedule: "0 2 * * *"
concurrencyPolicy: Forbid
successfulJobsHistoryLimit: 3
failedJobsHistoryLimit: 1
jobTemplate:
spec:
backoffLimit: 2
template:
spec:
restartPolicy: Never
containers:
- name: backup
image: myapp/backup:1.0
command: ["./backup.sh"]'0 2 * * *' means minute 0, hour 2, every day, every month, every day-of-week -- i.e. 02:00 every day. concurrencyPolicy: Forbid prevents a new Job from starting if the previous scheduled run is still active.
CronJob schedules are evaluated based on the kube-controller-manager's clock in UTC by default; missed schedules beyond startingDeadlineSeconds are simply skipped rather than queued up, so long controller downtime can cause silent gaps in execution.
- A Job runs Pods to completion; successful Pods are not restarted, matching restartPolicy Never or OnFailure only.
- backoffLimit caps retries; activeDeadlineSeconds sets an overall Job timeout.
- completions + parallelism together control how many Pods run and how many run concurrently for batch fan-out.
- A CronJob creates Jobs on a five-field cron schedule (minute hour day month weekday).
- concurrencyPolicy (Allow/Forbid/Replace) controls overlap behavior between scheduled runs.
- successfulJobsHistoryLimit and failedJobsHistoryLimit control how many completed Job objects are retained for inspection.
Practice what you learned
1. What restartPolicy values are valid for a Job's Pod template?
2. What does backoffLimit control on a Job?
3. In a CronJob, what does the schedule '0 2 * * *' mean?
4. What does concurrencyPolicy: Forbid do on a CronJob?
5. What combination of fields lets a Job process 10 work items with at most 3 running concurrently?
Was this page helpful?
You May Also Like
Deployments and ReplicaSets
Learn how Deployments manage ReplicaSets to declaratively run, scale, and update stateless Pod replicas in Kubernetes.
Kubernetes Monitoring and Logging
Learn the core tools and patterns for observing cluster and application health: metrics, logs, and the Prometheus/Grafana stack.
kubectl Basics
A practical introduction to kubectl, the command-line tool used to interact with a Kubernetes cluster's API server.
Docker & Kubernetes Quick Reference
A cheat-sheet of essential Docker CLI commands, kubectl commands, Dockerfile instructions, and kubectl resource shortnames for fast lookup.
Related Reading
Related Study Notes in DevOps
Browse all study notesNginx Study Notes
DevOps · 30 topics
DevOpsAnsible Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsCI/CD Tools & Pipelines Study Notes
YAML · 37 topics