DaemonSet vs Deployment — What's the Difference?

Detailed Answer

Both DaemonSets and Deployments manage Pods, but they solve different problems and have different scaling behaviors.

Core Difference

| Aspect | Deployment | DaemonSet | |---|---|---| | Scaling model | Fixed replica count | One Pod per eligible node | | Replica count | Explicitly set (e.g., replicas: 5) | Determined by node count | | Pod placement | Scheduler decides | One per node, guaranteed | | Auto-scales with cluster | No | Yes | | HPA support | Yes | No | | Use case | Application workloads | Node-level infrastructure |

Deployment Example

A Deployment with 3 replicas lets the scheduler decide placement. Pods might end up on 2 nodes or 3 nodes depending on resource availability and topology constraints:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-api
  template:
    metadata:
      labels:
        app: web-api
    spec:
      containers:
        - name: api
          image: myapp/web-api:v2
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: "250m"
              memory: "256Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"

DaemonSet Example

A DaemonSet does not have a replicas field. The number of Pods equals the number of eligible nodes:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-exporter
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: node-exporter
  template:
    metadata:
      labels:
        app: node-exporter
    spec:
      containers:
        - name: node-exporter
          image: prom/node-exporter:v1.7.0
          ports:
            - containerPort: 9100
              hostPort: 9100
          resources:
            requests:
              cpu: "50m"
              memory: "64Mi"
            limits:
              cpu: "200m"
              memory: "128Mi"
      hostNetwork: true
      hostPID: true

Scenario-Based Comparison

You need a log collector on every node → DaemonSet. Log collectors must have access to local log files on each node. A Deployment might skip nodes or double up.

You need a web API with 10 replicas → Deployment. The scheduler can pack Pods efficiently across nodes, and HPA can scale based on CPU or custom metrics.

You need a CNI plugin on every node → DaemonSet. Networking must be available before any other Pods can start, and every node needs it.

You need a background worker processing a queue → Deployment. Workers are interchangeable and should scale based on queue depth, not node count.

Update Strategy Differences

Both support rolling updates, but the mechanics differ:

Deployment rolling update:

• Creates new Pods before terminating old ones (controlled by maxSurge/maxUnavailable)
• Can exceed the desired replica count temporarily
• Maintains a ReplicaSet revision history for rollback

DaemonSet rolling update:

• Updates Pods node by node
• Terminates the old Pod on a node, then creates the new one
• Controlled by maxUnavailable (no maxSurge for DaemonSets by default)
• Can use maxSurge since Kubernetes 1.22 to create the new Pod before terminating the old one

# DaemonSet with maxSurge for zero-downtime updates
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-exporter
spec:
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 1

Resource Competition

DaemonSet Pods consume resources on every node, reducing capacity for application Pods. This is an important cluster planning consideration:

Node capacity: 4 CPU, 16 GB RAM
DaemonSet reservations: 0.5 CPU, 1 GB RAM (log collector + monitoring + CNI)
Available for applications: 3.5 CPU, 15 GB RAM

Keep DaemonSet resource requests minimal and set appropriate limits to prevent infrastructure Pods from starving application workloads.