Introduction

Deployments and DaemonSets are both Kubernetes controllers, but they answer different scheduling questions. A Deployment asks, "How many replicas of this application should exist?" A DaemonSet asks, "Which nodes should each run one copy of this pod?" Once you see that distinction, controller choice becomes much easier.

Deployments Manage Replica-Based Workloads

A Deployment is the standard controller for stateless applications such as APIs, web frontends, and queue workers. You tell Kubernetes how many replicas you want, and it keeps that number running by managing ReplicaSets and replacing failed pods.

1apiVersion: apps/v1
2kind: Deployment
3metadata:
4  name: payments-api
5spec:
6  replicas: 3
7  selector:
8    matchLabels:
9      app: payments-api
10  template:
11    metadata:
12      labels:
13        app: payments-api
14    spec:
15      containers:
16        - name: api
17          image: ghcr.io/example/payments-api:1.2.0
18          ports:
19            - containerPort: 8080

If load increases, you scale the Deployment by increasing replica count manually or through an autoscaler. The controller is concerned with service capacity, not node coverage.

DaemonSets Manage Node Coverage

A DaemonSet ensures that each eligible node runs one matching pod. When a new node joins the cluster, Kubernetes schedules a pod there automatically. When a node leaves, the corresponding pod disappears with it.

1apiVersion: apps/v1
2kind: DaemonSet
3metadata:
4  name: node-log-agent
5spec:
6  selector:
7    matchLabels:
8      app: node-log-agent
9  template:
10    metadata:
11      labels:
12        app: node-log-agent
13    spec:
14      containers:
15        - name: fluent-bit
16          image: cr.fluentbit.io/fluent/fluent-bit:2.2

This is the right fit for node-level agents such as log shippers, metrics collectors, security scanners, and storage helpers that need host-local presence.

Scaling Behavior Is Fundamentally Different

Deployment scaling is explicit. If you set replicas: 3, Kubernetes aims to keep three pods running regardless of how many nodes are in the cluster. A DaemonSet scales implicitly with the number of matching nodes. If you add five new worker nodes, you get five more DaemonSet pods without touching the manifest.

That difference is operationally important. A Deployment is for "run N copies." A DaemonSet is for "run one per node." If you pick the wrong one, the workload can appear to work at first and then fail to meet expectations during cluster changes.

Update Semantics Follow the Workload Goal

Deployments are built around rolling application updates, rollback history, and traffic-serving availability. DaemonSets also support rolling updates, but the goal is different. The goal is maintaining coverage across nodes while each node-local pod is refreshed.

Operational checks reflect that difference:

kubectl rollout status deployment/payments-api
kubectl get daemonset node-log-agent

For a Deployment, you care about desired versus available replicas. For a DaemonSet, you care about desired number scheduled, current number scheduled, and ready coverage across the targeted nodes.

Node Selection Matters More for DaemonSets

Both controllers can use labels, affinity, taints, and tolerations, but these settings are often more central for DaemonSets because they define exactly which nodes count as coverage targets. A node agent that misses tainted nodes or GPU nodes may silently leave observability or security gaps in the cluster.

By contrast, a Deployment usually cares more about spreading replicas for resilience than about touching every node. It may use anti-affinity to avoid co-locating all pods, but it does not usually require universal node presence.

Common Pitfalls

Teams often deploy host-level agents as Deployments and then wonder why some nodes have no collector running. The reverse mistake also happens: an API is deployed as a DaemonSet even though it only needs replica-based scaling. Another common problem is forgetting tolerations or selectors, which makes a DaemonSet appear healthy while skipping an important subset of nodes.

Summary

• A Deployment manages a chosen replica count for application workloads.
• A DaemonSet manages one pod per matching node for node-level services.
• Deployment scaling is explicit; DaemonSet scaling follows cluster topology.
• Pick the controller based on workload semantics, not because the YAML looks similar.
• Always verify either replica availability or node coverage after rollout.