Q: Difference between Deployment, StatefulSet, DaemonSet, and Job in Kubernetes.
Master deployment statefulset daemonset job workload controllers in Kubernetes. Master pod identity, persistent storage coupling, scheduling rules, and production selection criteria.
Want to master this scenario in a live sandbox? KodeKloud's CKA & CKAD Hands-On Certification Track covers this exact problem with hands-on terminal drills.
🛠️ Production Runbook & Step-by-Step Resolution
Direct Answer: In Kubernetes architecture interviews, comparing deployment statefulset daemonset job controllers is essential. Selecting the wrong workload controller can cause data loss, split-brain outages, or wasted compute. When addressing this question, I present an architectural decision matrix evaluating pod identities, storage lifecycles, rollout strategies, and failure domain recovery across all four controllers.
Kubernetes Deployment: Stateless Scalability & Rolling Updates
Deployments manage stateless application pods via ReplicaSets. Pods are completely interchangeable (cattle, not pets), have random non-sequential names, and can be created or destroyed on any worker node without loss of state.
apiVersion: apps/v1
kind: Deployment
metadata:
name: api-gateway
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25%
maxUnavailable: 0
template:
# Pod template...- Pod Naming: Randomized hashes (e.g.,
api-gateway-7489dfb8c-x9w2q). - Rollout Strategy: Automated rolling updates with
maxSurgeandmaxUnavailableguarantees. - Production Use Cases: Web applications, REST APIs, microservices, stateless message consumers.
Kubernetes StatefulSet: Ordered Quorum & Persistent Identity
StatefulSets manage stateful applications requiring unique, stable network identities and dedicated persistent storage per replica. Pods are created sequentially from 0 to N-1 and terminated in reverse order.
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: redis-cluster
spec:
serviceName: redis-headless
replicas: 3
volumeClaimTemplates:
- metadata:
name: redis-data
spec:
accessModes: [ "ReadWriteOnce" ]
resources:
requests:
storage: 50Gi- Stable Pod Identity: Predictable ordinal indexing (
redis-cluster-0,redis-cluster-1). - Headless DNS Routing: Direct peer-to-peer discovery via
redis-cluster-0.redis-headless.production.svc.cluster.local. - Dedicated Storage Binding: Uses
volumeClaimTemplatesso each pod retains its specific PersistentVolume across restarts and rescheduling. - Production Use Cases: Kafka brokers, PostgreSQL clusters, Cassandra nodes, Elasticsearch masters.
Kubernetes DaemonSet: Node-Level Infrastructure Services
A DaemonSet ensures that all (or matching) worker nodes run exactly one copy of a pod. As new nodes join the cluster, DaemonSet pods are automatically scheduled on them.
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fluentbit-collector
namespace: logging
spec:
selector:
matchLabels:
name: fluentbit
template:
# Node agent template...- Scheduling Logic: Schedules pods via node affinity and tolerations, running on master and worker nodes alike.
- Host Resource Access: Frequently mounts host filesystems (
/var/log,/var/run/docker.sock) usinghostPathvolumes. - Production Use Cases: Log collectors (Fluentbit, Promtail), monitoring node exporters (Prometheus Node Exporter), CNI agents (Cilium, Calico, AWS VPC-CNI).
Kubernetes Job & CronJob: Run-to-Completion Batch Processing
Unlike Deployments which ensure pods run indefinitely, a Job runs pods until a specified number of successful completions (completions) is achieved, terminating with exit code 0.
apiVersion: batch/v1
kind: Job
metadata:
name: db-migration-v2
spec:
backoffLimit: 3
activeDeadlineSeconds: 600
template:
spec:
restartPolicy: OnFailure
containers:
- name: flyway
image: flyway/flyway:latest
args: ["migrate"]- Lifecycle Semantics:
restartPolicy: OnFailureorNever. Terminates cleanly upon task completion. - Failure Safeguards:
backoffLimithandles retries;activeDeadlineSecondsterminates runaway or deadlocked processes. - Production Use Cases: Database schema migrations (Flyway, Liquibase), scheduled backups, machine learning batch inferencing, reporting scripts.
Deployment StatefulSet DaemonSet Job Decision Matrix
Comprehensive decision matrix comparing deployment statefulset daemonset job controllers across essential production dimensions:
- Deployments manage interchangeable stateless pods via ReplicaSets with automated rolling updates (e.g. Nginx, microservices).
- StatefulSets provide persistent ordinal naming (pod-0), headless DNS routing, and dedicated PVCs per replica for clustered databases (e.g. Kafka, Postgres).
- DaemonSets guarantee exactly one pod per node across the cluster for node-level operations (e.g. Fluentbit log shipping, Cilium CNI).
- Jobs supervise run-to-completion batch tasks with retry limits and automated termination upon success (e.g. Flyway DB migrations, daily backups).
Senior hiring managers and bar raisers evaluate how you prioritize during outages. Avoid these common anti-patterns:
- Using a Deployment with ReadWriteOnce PVCs for scaled replicas ReadWriteOnce EBS volumes can only attach to a single worker node; scaling replicas scheduled on different nodes will fail with Multi-Attach errors.
- Running database migrations inside a Deployment container lifecycle If a Deployment runs 5 replicas, all 5 pods will execute migrations concurrently, causing database lock contention and schema race conditions.
- Deleting a StatefulSet expecting its PVCs to be cleaned up automatically StatefulSet PVCs are intentionally retained to prevent accidental data loss; deleting the StatefulSet leaves orphaned PVCs incurring cloud storage bills.
- Forgetting backoffLimit and activeDeadlineSeconds on Kubernetes Jobs A crashing Job without limits will continuously retry and spin up failed pods indefinitely, consuming cluster CPU and filling node disk space with logs.