K8s Workload Types Compared: Deployment, StatefulSet, DaemonSet, Job

Four Kubernetes workload primitives, each purpose-built for a specific operational pattern. Picking the wrong one leads to subtle pain.

Deployment — the 90% default

• For stateless services where pods are interchangeable: web APIs, microservices, background workers, frontends
• Manages ReplicaSets which manage Pods; rolling updates are the default; rollback via kubectl rollout undo
• Random pod names (web-abc123); pod can be killed and recreated anywhere with no consequence beyond load distribution

StatefulSet — for systems that need stable identity

• For databases (MySQL, Postgres, Mongo), distributed systems (Kafka, ZooKeeper, Cassandra, Elasticsearch)
• Pods get deterministic ordinal names (mysql-0, mysql-1, mysql-2) and stable DNS via a headless service
• Each pod gets its own PersistentVolumeClaim from volumeClaimTemplates; PVC follows the pod through rescheduling
• Rollouts are sequential — pods come up one at a time in order, waiting for each Ready before starting the next; safer for stateful systems but slower

The most common StatefulSet mistake

• Using one when the database is actually external (RDS, Aurora, managed Mongo)
• If your application connects to an external DB, the application is stateless from K8s's perspective — use a Deployment
• StatefulSets are only for when K8s is managing the stateful workload itself

DaemonSet — one pod per node

• For node-level agents: log collectors (Fluentd, Vector), monitoring agents (Datadog, Prometheus node-exporter), CSI drivers, network plugins like kube-proxy
• As you add nodes, the DaemonSet automatically schedules a pod on each new one
• Respects node selectors and tolerations — you can run on all nodes, only Linux nodes, only GPU nodes
• Common gotcha: DaemonSets don't run on tainted nodes by default; need explicit tolerations for control-plane nodes

Job and CronJob — run to completion or on schedule

• Job runs pods until they complete successfully (rather than restarting indefinitely)
• Use for database migrations on deploy, one-time data migrations, batch processing
• CronJob is Job plus a cron schedule — K8s equivalent of crontab; backups, scheduled reports
• Set ttlSecondsAfterFinished to auto-clean completed Job pods; without it they accumulate
• Set concurrencyPolicy on CronJobs — default Allow means overlapping runs if a job exceeds its interval; usually want Forbid or Replace

The bigger question

• Should you really self-host stateful systems on K8s? The pendulum has swung — operators (Cloudnative-PG, Strimzi for Kafka, Elasticsearch operator) make self-hosting more reliable
• But for production at scale, managed services (RDS, MSK, Elastic Cloud) eliminate operational burden
• Use StatefulSet when managed isn't an option (cost, regulatory, multi-cloud) or when you have a dedicated platform team

Operational pitfalls to call out

• StatefulSet scale-down doesn't delete PVCs (data preservation); orphaned PVCs accumulate and need cleanup
• DaemonSet scaling: adding a node spins up all your DaemonSet pods; with 50 DaemonSets that's 50 extra pods per new node
• Job retries can hide failures — default backoffLimit of 6 means a broken Job retries 6 times before giving up; tune for your context