The Right Tool for the Job
Think of how a hotel manages its rooms versus how a family manages its pets. Hotel rooms are interchangeable — if room 204 has a plumbing issue, they move you to room 207 and nobody cares about the room number. But pets are individuals: your dog Max has a name, a history, a vet record, and you'd notice immediately if he were replaced with a different dog.
Kubernetes Deployments manage Pods like hotel rooms — interchangeable, disposable, and randomly named. If a Pod named web-xhk12 dies, Kubernetes replaces it with web-99sqa and the application doesn't skip a beat. This works perfectly for stateless applications like web servers, where any Pod can handle any request.
But not all applications are stateless. A database cluster needs its nodes to have stable identities so peers can find each other. A log collection agent needs to run on every server in your cluster, not just a fixed number of them. A database migration script needs to run exactly once and stop — not restart in a loop. These scenarios require specialized workload controllers that Kubernetes provides beyond the standard Deployment.
The four workload types covered in this topic are:
| Workload | Use Case |
|---|---|
| StatefulSet | Stateful apps needing stable identity and persistent storage |
| DaemonSet | One Pod per node (log agents, monitoring, storage daemons) |
| Job | Run-to-completion tasks (migrations, batch processing) |
| CronJob | Scheduled run-to-completion tasks (nightly backups, reports) |
Understanding when to reach for each of these — and why using the wrong one causes subtle, hard-to-debug failures — is a core Kubernetes competency.