Q: In Kubernetes, what is the difference between Deployment, StatefulSet, and DaemonSet?
Clear decision matrix distinguishing Kubernetes Deployment, StatefulSet, and DaemonSet controllers, covering pod identity, network identity, persistent volume lifecycle, and per-node scheduling.
#Kubernetes #Workloads #Deployment #StatefulSet #DaemonSet #Storage
🎙️ Candidate Opening & Architectural Context
"In production, selecting the wrong workload controller leads to data corruption, deployment deadlocks, or wasted compute. I categorize them by statefulness, pod identity, and placement topology."
Advertisement
🛠️ Production Runbook & Step-by-Step Resolution
1️⃣
Deployment: Stateless, Interchangeable Workloads
Designed for stateless microservices, web apps, and API gateways where pods are ephemeral and interchangeable:
- Pod Identity: Pods receive random hash suffixes (e.g.
api-7d58f97b6b-4kx9l). Any pod can serve any request. - Storage: Typically stateless. If mounting PersistentVolumes (PV), all replicas share the same ReadWriteMany (NFS/EFS) volume or ephemeral emptyDir.
- Rollouts: Controlled by ReplicaSets with declarative RollingUpdate or Recreate strategies.
2️⃣
StatefulSet: Ordered, Stateful & Identity-Preserving Workloads
Designed for databases, distributed storage, and clustered systems (Kafka, Elasticsearch, PostgreSQL, Redis Cluster, ZooKeeper):
- Predictable Identity: Pods get deterministic, zero-indexed ordinal names (e.g.
kafka-0,kafka-1,kafka-2). - Headless Service & DNS: Uses
clusterIP: Noneso each pod receives a distinct DNS entry (e.g.kafka-0.kafka-headless.prod.svc.cluster.local) essential for leader election and cluster peering. - volumeClaimTemplates: Each replica dynamically provisions its own dedicated, persistent disk that survives pod recreation or rescheduling.
- Ordered Deployment & Termination: Deploys sequentially (0 ➔ 1 ➔ 2) and shuts down in reverse order to preserve quorum.
3️⃣
DaemonSet: Exactly One Pod Per Node Workloads
Ensures that a copy of the pod runs on every matching node in the cluster:
- Node-Bound Placement: Pods are automatically scheduled when a new node joins the cluster and garbage collected when the node is decommissioned.
- Primary Use Cases: Cluster observability agents (Datadog, Fluentbit, Prometheus Node Exporter), networking CNI plugins (Calico, AWS VPC CNI, Cilium), and security runtimes (Falco, Sysdig).
- Tolerations: DaemonSets typically tolerate
node.kubernetes.io/unschedulableand master/control-plane taints to monitor every physical host.
💡 The Senior SRE Gold Nugget (Key Architectural Takeaway)
"Use Deployments for interchangeable stateless APIs; StatefulSets for quorum-based, disk-backed databases needing deterministic DNS and storage; and DaemonSets for infrastructure agents (CNI, logging, metrics, security) that must live on every physical node."
⚡ 60-Second Elevator Pitch Talking Points
- Deployment: Stateless apps (APIs, web apps); random pod hashes; shared or no persistent disk; rolling updates.
- StatefulSet: Clustered databases (Kafka, Postgres, Redis); deterministic ordinal names (app-0, app-1); dedicated volumeClaimTemplates; headless service DNS.
- DaemonSet: Infrastructure agents (Fluentbit, Node Exporter, Cilium, Falco); runs exactly one pod per node automatically as nodes scale.
- Pro-Tip: Never run databases on Deployments with ReadWriteOnce EBS volumes—pods will fail to remount across nodes due to multi-attach errors.
Advertisement