Stateful, daemon, and batch workloads
StatefulSets, DaemonSets, Jobs, and CronJobs — when Deployments are the wrong tool.
Deployments fit stateless replicas. Other controllers exist because identity, node coverage, or finite work need different guarantees.
StatefulSet
Stable network identity (pod-0, pod-1), ordered deploy/scale, and PVC per ordinal. Use for clustered datastores and systems that need sticky identity — with operators/backup expertise. A StatefulSet alone is not a managed database product.
DaemonSet
One Pod per matching node (or per selected nodes). Typical for CNI helpers, log agents, node exporters, security agents. Updates roll node-by-node; bad DaemonSets can affect the whole fleet — treat them as platform-critical.
Job
Run Pods to completion. Control parallelism and completions; decide restart policy for failure. Use for migrations, index builds, batch reports. A Job that never completes blocks dependents if you wait on it blindly.
CronJob
Time-based Job creation. Watch concurrencyPolicy, history limits, and timezone behavior. Missed runs and overlapping jobs are common production surprises — make jobs idempotent.
Choosing deliberately
| Need | Prefer |
|---|---|
| Stateless HTTP API | Deployment |
| Stable identity + storage | StatefulSet (+ operator) |
| Every node agent | DaemonSet |
| Finite work | Job / CronJob |
If you force a database into a Deployment with a single PVC, you chose the wrong controller.