Beyond Stateless Deployments
Deployments assume Pods are interchangeable and stateless. Some workloads break that assumption: databases need stable identity and dedicated storage per replica, and infrastructure agents (log shippers, monitoring agents) need to run on every node exactly once. StatefulSets and DaemonSets are the controllers built for these two distinct needs.
Cricket analogy: A T20 franchise can swap any net bowler into a warm-up game (stateless Pods), but the designated wicketkeeper and No.3 batter need continuity match after match, while the ground curator must service every venue in the tournament exactly once -- two different jobs, two different controllers.
StatefulSets: Stable Identity and Ordered Operations
A StatefulSet gives each Pod a stable, predictable name (web-0, web-1, web-2, ...), a stable network identity via a headless Service, and its own persistent storage that survives rescheduling. Pods are created, scaled, and terminated in strict order (0, then 1, then 2, ...) by default, which matters for clustered databases with leader election or ordered bootstrap requirements.
Cricket analogy: Numbering batters web-0, web-1, web-2 is like a fixed batting order where No.3 always walks in third, each with their own reserved locker (storage) and a stable commentary-box identity (network name) that survives even if they're stretchered off and return later.
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: web
spec:
serviceName: web-headless
replicas: 3
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- name: web
image: postgres:16
ports:
- containerPort: 5432
volumeMounts:
- name: data
mountPath: /var/lib/postgresql/data
volumeClaimTemplates:
- metadata:
name: data
spec:
accessModes: ["ReadWriteOnce"]
storageClassName: standard
resources:
requests:
storage: 10GiThe volumeClaimTemplates field is what makes StatefulSets special: Kubernetes automatically creates a unique PersistentVolumeClaim per Pod replica (data-web-0, data-web-1, ...), and that same PVC is re-attached if the Pod is rescheduled, preserving data across restarts.
Cricket analogy: volumeClaimTemplates is like automatically issuing each batter (web-0, web-1) their own personal kit bag (data-web-0, data-web-1) that follows them if they're substituted and brought back into the same batting slot, so their gear never gets mixed up with a teammate's.
StatefulSets require a headless Service (clusterIP: None) referenced by spec.serviceName, so each Pod gets a stable DNS record like web-0.web-headless.default.svc.cluster.local.
DaemonSets: One Pod Per Node
A DaemonSet ensures that a copy of a Pod runs on every node (or every node matching a nodeSelector/affinity rule) in the cluster, automatically adding a Pod when a new node joins and removing it when a node is removed. It has no replicas field -- the node count determines the Pod count.
Cricket analogy: A DaemonSet is like assigning one groundsman to every single stadium in the league automatically -- when a new venue is added to the fixture list, a groundsman is deployed there too, and when a venue is dropped, theirs leaves with it.
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: log-agent
spec:
selector:
matchLabels:
app: log-agent
template:
metadata:
labels:
app: log-agent
spec:
tolerations:
- key: node-role.kubernetes.io/control-plane
effect: NoSchedule
containers:
- name: log-agent
image: fluent-bit:2.2
volumeMounts:
- name: varlog
mountPath: /var/log
volumes:
- name: varlog
hostPath:
path: /var/logDaemonSets typically need explicit tolerations to schedule Pods onto tainted nodes such as control-plane nodes, since those are excluded from normal scheduling by default taints.
Common Use Cases
Typical StatefulSet workloads: PostgreSQL, MySQL, Kafka, Zookeeper, Elasticsearch data nodes -- anything needing stable network identity or per-replica storage. Typical DaemonSet workloads: log collectors (Fluentd/Fluent Bit), node monitoring agents (node-exporter), network plugins (CNI agents), and storage drivers (CSI node plugins).
Cricket analogy: StatefulSets suit a franchise's core batting order (needing stable slots like PostgreSQL needs stable identity), while DaemonSets suit ground staff -- scorers, physios, security -- who must be present at every single venue, akin to log collectors on every node.
- StatefulSets give Pods stable names, stable DNS via a headless Service, and per-replica persistent storage through volumeClaimTemplates.
- StatefulSet Pods are created/deleted in ordinal order (0,1,2,...) by default, unlike Deployments.
- DaemonSets run exactly one Pod per matching node and have no replicas field -- node count drives Pod count.
- DaemonSets often need tolerations to run on tainted nodes like control-plane nodes.
- PVCs created by a StatefulSet are not deleted automatically when the StatefulSet is deleted (data safety by default).
- Use StatefulSets for databases/clustered stateful apps; use DaemonSets for node-level infrastructure agents.
Practice what you learned
1. What field in a StatefulSet spec automatically provisions a unique PersistentVolumeClaim per replica?
2. By default, in what order does a StatefulSet create its Pods?
3. What determines the number of Pods a DaemonSet runs?
4. Why do DaemonSets often need tolerations defined in their Pod spec?
5. What is required for StatefulSet Pods to get stable, individually addressable DNS names?
Was this page helpful?
You May Also Like
Persistent Volumes and Claims
Learn how Kubernetes decouples storage from Pods using PersistentVolumes, PersistentVolumeClaims, and StorageClasses for durable, dynamically provisioned data.
Services and Networking
Understand how Kubernetes Services provide stable networking identities and load balancing for ephemeral, dynamically scheduled Pods.
Deployments and ReplicaSets
Learn how Deployments manage ReplicaSets to declaratively run, scale, and update stateless Pod replicas in Kubernetes.
Kubernetes Monitoring and Logging
Learn the core tools and patterns for observing cluster and application health: metrics, logs, and the Prometheus/Grafana stack.
Related Reading
Related Study Notes in DevOps
Browse all study notesNginx Study Notes
DevOps · 30 topics
DevOpsAnsible Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsCI/CD Tools & Pipelines Study Notes
YAML · 37 topics