We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
This idea carries a full system design question on its own. Each walks through the full answer.
System Design Masterclass · Kubernetes Containers
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Kubernetes Containers
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
Deployments are designed for long-running services: web servers, APIs, background workers that process indefinitely. But many workloads are finite. Generate a nightly report. Process a batch of 10,000 images. Send weekly email digests. Clean up expired sessions. Run a database backup.
These tasks need to start, do their work, and stop. Running them as a Deployment is wrong in two ways. First, the Deployment controller restarts the pod after it exits, which means your completed backup starts running again for no reason. Second, the Deployment keeps the pod alive permanently, consuming CPU and memory while doing nothing between runs.
Jobs are Kubernetes' answer to finite tasks. A Job creates one or more pods, waits for them to complete successfully, and marks itself as done. The pod is not restarted on success. A CronJob is a Job on a schedule, like cron on Linux but with Kubernetes' reliability guarantees: retry on failure, concurrency control, deadline enforcement, and history tracking.
Stripe runs thousands of CronJobs across their Kubernetes fleet for tasks like billing cycle processing, compliance report generation, and data pipeline orchestration. Each CronJob has explicit timeouts, retry limits, and monitoring, because a missed nightly billing run means real revenue impact.
Job: Runs a task to completion.
apiVersion: batch/v1
kind: Job
metadata:
name: db-backup
spec:
completions: 1 # How many successful pod runs needed
parallelism: 1 # How many pods run simultaneously
backoffLimit: 3 # Retry attempts before marking Failed
activeDeadlineSeconds: 3600 # Kill the job after 1 hour
ttlSecondsAfterFinished: 86400 # Clean up 24h after completion
template:
spec:
restartPolicy: Never
containers:
- name: backup
image: postgres:16
command: ["pg_dump", "-h", "db", "-o", "/backup/dump.sql"]
CronJob: Runs a Job on a schedule.
apiVersion: batch/v1
kind: CronJob
metadata:
name: nightly-backup
spec:
schedule: "0 2 * * *" # Every day at 2 AM UTC
concurrencyPolicy: Forbid # Skip if previous run still going
startingDeadlineSeconds: 600 # Give up if 10 min late
successfulJobsHistoryLimit: 3 # Keep last 3 successful Jobs
failedJobsHistoryLimit: 1 # Keep last 1 failed Job
jobTemplate:
spec:
# ... same as Job spec above
| Feature | Job | CronJob |
|---|---|---|
| Trigger | Manual (kubectl apply) or API call | Cron schedule |
| Runs | Once | Repeatedly on schedule |
| Parallelism | Configurable (1 to N pods) | Inherits from Job spec |
| Retry | backoffLimit with exponential backoff | Per-run backoffLimit |
| Concurrency | N/A | Allow, Forbid, or Replace |
| Cleanup | ttlSecondsAfterFinished | History limits |