Jobs and CronJobs
A Job is a controller for running pods that are meant to finish, not run forever — batch processing, database migrations, one-off scripts. It tracks successful completions and retries failed pods according to backoffLimit, and unlike a Deployment, it considers itself done once the required number of pods have exited successfully rather than continuously reconciling toward a persistent replica count.
Cricket analogy: Like a specific chase target in a limited-overs match — once the team reaches the required run total, the innings is complete and done, unlike a Test match's open-ended, ongoing pursuit of dominance across days.
Job Completion Modes
The completions field sets how many pods must succeed for the Job to be done, and parallelism caps how many run at once. For workloads where each pod should process a distinct slice of work, Indexed completion mode assigns each pod a unique index via the JOB_COMPLETION_INDEX environment variable, letting pods self-select their partition of data — for example, pod index 3 processes shard 3 of an input dataset.
Cricket analogy: Like a net-practice session where 6 bowlers each bowl to a specific numbered batter in rotation, each knowing their assigned slot, rather than all bowling randomly at whoever is available.
apiVersion: batch/v1
kind: Job
metadata:
name: data-shard-processor
spec:
completions: 10
parallelism: 4
completionMode: Indexed
backoffLimit: 3
activeDeadlineSeconds: 1800
ttlSecondsAfterFinished: 3600
template:
spec:
restartPolicy: Never
containers:
- name: shard-processor
image: registry.example.com/shard-processor:1.2.0
env:
- name: SHARD_INDEX
valueFrom:
fieldRef:
fieldPath: metadata.annotations['batch.kubernetes.io/job-completion-index']
resources:
requests:
cpu: 500m
memory: 512MiCronJobs: Scheduling Recurring Jobs
A CronJob creates a new Job on a schedule expressed in standard cron syntax, such as "0 2 * * *" for 2 AM daily. concurrencyPolicy governs overlap: Allow lets multiple runs execute concurrently, Forbid skips a new run if the previous one is still active, and Replace cancels the running Job and starts the new one. startingDeadlineSeconds bounds how late a missed schedule can still be honored before Kubernetes gives up on that particular run.
Cricket analogy: Like a franchise's fixed pre-season fitness test scheduled every morning at 6 AM — if a player is still finishing yesterday's session when today's starts, the policy decides whether to run both simultaneously, skip today's, or cut yesterday's short.
successfulJobsHistoryLimit and failedJobsHistoryLimit control how many completed and failed Job objects a CronJob retains for inspection, defaulting to 3 and 1 respectively — tune these up temporarily when debugging a flaky scheduled job, then reduce them again to limit clutter.
Failure Handling and TTL Cleanup
backoffLimit sets how many times a Job retries a failing pod before marking the Job itself as failed, with an exponential back-off delay between attempts. activeDeadlineSeconds caps the total wall-clock time a Job is allowed to run before being terminated regardless of retries. Once a Job finishes, ttlSecondsAfterFinished schedules automatic deletion of the Job and its pods after that many seconds, preventing completed Jobs from accumulating indefinitely in the cluster.
Cricket analogy: Like a bowler getting a maximum of 3 no-ball reviews before the umpire stops entertaining further appeals for that delivery type, combined with a hard stop at the 50-over mark regardless of how the innings is progressing.
If the CronJob controller itself is down or a run is missed past startingDeadlineSeconds, that scheduled execution is simply skipped rather than queued — CronJobs are not a guaranteed at-least-once scheduler, so critical time-sensitive jobs need external monitoring to detect missed runs.
- A Job runs pods to completion and tracks successes, unlike a Deployment's continuously running replicas.
- completions and parallelism control how many pods must succeed and how many run concurrently.
- Indexed completion mode gives each pod a JOB_COMPLETION_INDEX to self-select a data partition.
- CronJobs create Jobs on a cron schedule; concurrencyPolicy governs overlap (Allow/Forbid/Replace).
- backoffLimit and activeDeadlineSeconds bound retries and total runtime for failure handling.
- ttlSecondsAfterFinished automatically garbage-collects completed Jobs and their pods.
- startingDeadlineSeconds means missed schedules can be silently skipped, not guaranteed to run.
Practice what you learned
1. How does a Job differ fundamentally from a Deployment?
2. What does completionMode: Indexed provide to each pod in a Job?
3. What does concurrencyPolicy: Forbid do on a CronJob?
4. What is the purpose of ttlSecondsAfterFinished?
5. What happens if a CronJob's scheduled run is missed past startingDeadlineSeconds, e.g. because the controller was down?
Was this page helpful?
You May Also Like
Deployments In Depth
How Kubernetes Deployments manage ReplicaSets to deliver declarative rolling updates, rollbacks, and self-healing for stateless workloads.
Pod Disruption Budgets
How PodDisruptionBudgets protect application availability during voluntary disruptions like node drains, upgrades, and cluster autoscaler actions.
DaemonSets Explained
How DaemonSets guarantee exactly one pod per matching node for node-level infrastructure like log collectors, monitoring agents, and CNI plugins.