StatefulSet and DaemonSet in Kubernetes Explained With Real-World Examples ✌️

Real-World Analogy: Stateless vs Stateful

Let’s take a real-world example.

A customer is having an issue with a package delivery, so he calls a live support agent. He explains the entire problem in detail. Unfortunately, the call gets disconnected due to a network issue.
When the customer calls again, there is no guarantee the same agent will pick up the call, so he has to explain everything all over again. Eventually, the issue gets resolved—but a lot of time and effort is wasted.

This is exactly how stateless systems behave.

Now, imagine a different scenario:
The agent remembers the customer’s issue, previous conversation, and progress even if the call drops. When the customer reconnects, the agent continues from where they left off. No repetition. No wasted time.

That’s a stateful system.

Mapping This to Kubernetes Pods

Similarly, consider Kubernetes pods.

If a pod stores data only in its memory and that pod gets deleted or recreated, all the data is lost. When a new pod is created, it starts fresh there’s no way to recover the previous in-memory data.

For application pods, this is usually fine. These applications are designed to be stateless, meaning they don’t store critical data in real time.

But what if the pod is running a database?

If a database pod is deleted and all its data is lost, that’s a disaster. Everything would be wiped out.

Stateless vs Stateful Applications

• Stateless applications

  • Do not store data locally

  • Can be easily restarted or recreated

  • Commonly used for web applications, APIs, and microservices

• Stateful applications

  • Store and depend on persistent data

  • Require stable identity and storage

  • Commonly used for databases, message queues, and storage systems

That’s why Kubernetes provides StatefulSets to handle applications that need persistent data, stable identities, and ordered operations.

Feature	Stateless Application	Stateful Application
Definition	Does not store data or session state	Stores and depends on persistent data
Data storage	No persistent data	Persistent data required
Pod restart impact	No impact	Can impact data if not managed
Pod identity	No fixed identity	Stable, unique identity (pod-0, pod-1…)
Pod creation order	Pods are created in parallel (no order)	Pods are created one by one (ordered)
Pod deletion order	Pods can be deleted at the same time	Pods are deleted in reverse order (LIFO)
Scaling behavior	Fast and simple	Controlled and ordered
Kubernetes object	Deployment / ReplicaSet	StatefulSet
Storage	Usually no PVC	Uses PVC per pod
Use cases	Web apps, APIs	Databases, queues

Manifest File for StatefulSet

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: myfirst-statefulset
spec:
  serviceName: "nginx"        # mandatory for StatefulSet
  replicas: 2
  selector:
    matchLabels:
      app: swiggy
  template:
    metadata:
      labels:
        app: swiggy
    spec:
      containers:
        - name: mycont1
          image: nginx
          ports:
            - containerPort: 80

When working with Kubernetes, especially StatefulSets, one concept that often confuses beginners is the Headless Service. Let’s break it down in a simple and practical way.

In a normal Kubernetes setup using Deployments:

• Pods are stateless

• Pod names and IPs keep changing

• Traffic is distributed randomly using a Service

This is perfectly fine for applications like web servers.

But what if you are running a stateful application like:

• Databases (MySQL, MongoDB)

• Messaging systems (Kafka)

A Headless Service is simply a Service without a ClusterIP.

clusterIP: None

Normal Service (ClusterIP)

• Has a single IP

• Performs load balancing

Client → Service → Random Pod

Headless Service

• No ClusterIP

• No load balancing

• Returns all Pod IPs

Client → Gets all Pod IPs → Connects to specific Pod

StatefulSet creates pods with fixed names like:

myapp-0
myapp-1

But how do we access them individually?

This is where Headless Service helps.

It creates DNS entries like:

myapp-0.my-service
myapp-1.my-service

Client → Headless Service → Returns Pod IPs → Client selects Pod

---

DaemonSet

Let’s take a real-world example.

In a city like Mumbai, there are multiple types of crimes happening—betting, drugs, human trafficking, and more. The police cannot monitor everything at once from a single place. So, they decide to deploy spies, placing one spy for each activity/location, continuously monitoring and collecting evidence.
This way, no area is left unmonitored, and criminals can be caught red-handed.

Mapping This to Kubernetes DaemonSet

Similarly, in a Kubernetes cluster, we may want to monitor every node.

For this purpose, Kubernetes provides a DaemonSet.

• A DaemonSet ensures that exactly one pod runs on each node

• These pods act like spies or agents, continuously monitoring the node

• You do not define replicas in a DaemonSet

• When a new node is added, a pod is automatically created on that node

• When a node is removed, the pod is automatically deleted

Why DaemonSet is Used

DaemonSets are mainly used for node-level tasks, such as:

• Log collection

• Monitoring

• Security scanning

• Networking components

Feature	Kubelet	DaemonSet
What it is	Node-level agent/process	Kubernetes controller/object
Runs where	Runs on every node	Defined in control plane
Purpose	Ensures pods run as instructed	Ensures one pod per node
Pod creation	Executes pods assigned to the node	Decides that a pod should run on each node
Resource monitoring	Collects CPU/memory usage on its node	Does not collect metrics by itself
Scaling	Not applicable	Automatically scales with node count
Replicas	Not configurable	No replicas field
Node addition	Already running on new node	Creates pod automatically on new node
Node removal	Stops managing pods on removed node	Deletes pod from removed node
Metrics usage	Exposes metrics to metrics-server	Often used to deploy monitoring agents
Examples	Core Kubernetes component	Fluentd, Node Exporter, Calico

Manifest File for DaemonSet

---
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-monitor
  labels:
    app: monitoring
spec:
  selector:
    matchLabels:
      app: monitoring
  template:
    metadata:
      labels:
        app: monitoring
    spec:
      containers:
        - name: monitor-agent
          image: nginx
          ports:
            - containerPort: 80

Conclusion

Understanding the differences between StatefulSets and DaemonSets is essential for managing Kubernetes workloads effectively. StatefulSets are designed for applications that require persistent data and stable identities, such as databases and message queues. They ensure that each pod has a unique identity, predictable ordering, and retains its state across restarts.

In contrast, DaemonSets focus on node-level responsibilities. They guarantee that exactly one pod runs on every node, making them ideal for tasks like monitoring, log collection, networking, and security enforcement.

By choosing the right Kubernetes object for the right use case, you can build clusters that are not only scalable but also reliable and efficient—meeting both application-level and infrastructure-level requirements with confidence.

If you found this guide useful, please like ❤️, comment, and share your thoughts or questions. Stay tuned for the next part, where we'll explore advanced Docker concepts and practices.

Thank you,
Yours, Rama Grandhi