Medium15 minContainer Orchestration
UpdatedAug 2, 2026
Edit

Deployment vs. StatefulSet vs. DaemonSet

CONCEPTS:Kubernetes Workload Types

Question Variations

  • "When should you use a `StatefulSet` instead of a `Deployment`?"
  • "What is a `DaemonSet`, and what are its typical use cases?"
  • "How does Kubernetes handle Pod naming and network identity differently in a `StatefulSet` compared to a `Deployment`?"
  • "Explain how rolling updates work for a `DaemonSet`."

Why This Is Asked

Choosing the right controller is critical for application stability. Interviewers want to see if you understand the fundamental difference between stateless and stateful applications and how Kubernetes handles node-level infrastructure.

Key Concepts

  • Stateless vs. Stateful: Why databases need more care than web APIs.
  • Identity: Random Pod names vs. predictable ordinal indices.
  • Storage Persistence: How volumes are mapped to specific Pod instances.
  • Node Coverage: Ensuring a process runs on every machine in the cluster.

Question Variations

  • “When should you use a StatefulSet instead of a Deployment?”
  • “What is a DaemonSet, and what are its typical use cases?”
  • “How does Kubernetes handle Pod naming and network identity differently in a StatefulSet compared to a Deployment?”
  • “Explain how rolling updates work for a DaemonSet.”

Answers by Technology

+ Add Variant
KubernetesImprove this answer ✏️

Expected Answer

The choice of controller depends on the nature of the application:

  1. Deployment is for stateless apps. Pods are treated as “cattle”—if one dies, a new one replaces it with a new name and no memory of the past. It’s perfect for web servers and APIs.
  2. StatefulSet is for stateful apps like databases (Postgres, MongoDB). Pods are treated as “pets”—each has a unique, stable identity (app-0, app-1) and a specific persistent volume that follows it if it moves to a different node.
  3. DaemonSet ensures that every node in the cluster runs a copy of the Pod. This is used for system-level services like logging agents, monitoring agents, or network plugins.

Why It Matters

Using a Deployment for a database is a common disaster: if the Pod moves, it might lose its data or its identity, breaking the cluster’s consistency. Conversely, using a StatefulSet for a stateless API adds unnecessary complexity to scaling and updates.

Example Use Cases

  • Deployment: A React frontend, a Node.js API, a stateless microservice.
  • StatefulSet: A MySQL cluster, a Redis instance with persistence, a Kafka broker.
  • DaemonSet: Fluentd (logging), Prometheus Node Exporter (metrics), Calico (networking).

Common Mistakes

  • Using Deployment for Databases: Forgetting that Deployments don’t guarantee stable network IDs or volume affinity.
  • Overusing StatefulSet: Using it for things that don’t actually need it, which slows down rolling updates (because they happen one-by-one).
  • Forgetting DaemonSet for Infra: Running a logging agent as a Deployment instead of a DaemonSet, which might result in some nodes not being covered.

Follow-up Questions

  • How does a StatefulSet handle updates? (Answer: It updates Pods one at a time, usually in reverse ordinal order, waiting for the previous one to be healthy before moving to the next).
  • What is a “Headless Service” in the context of a StatefulSet? (Answer: A service without a cluster IP that allows direct DNS resolution of each Pod’s individual IP, which is required for peer-to-peer communication in distributed databases).
  • Can you limit a DaemonSet to only specific nodes? (Answer: Yes, using nodeSelector or nodeAffinity).

References