| Applies to | Any Kubernetes cluster |
|---|---|
| Cert prep | CKA · CKAD |
| Scope | Deployment versus DaemonSet comparison: placement, scaling, updates, scenarios, misunderstandings, and a decision checklist. Does not cover full Deployment or DaemonSet YAML, node affinity depth, taints tutorial, rollout commands, or monitoring platform install. |
| Related guides | Kubernetes ReplicaSet Pod versus Deployment Deployment versus StatefulSet Kubernetes labels and selectors Kubernetes namespaces |
For application tiers, start with a Deployment. Reach for a DaemonSet when the workload must run once on every eligible node — log shippers, monitoring exporters, or other node-level agents. This guide compares the two controllers so you can decide, then open the dedicated tutorials for manifests and operations.
Deployment vs DaemonSet Comparison
| Feature | Deployment | DaemonSet |
|---|---|---|
| Pod count | Defined by spec.replicas |
Based on eligible nodes |
| Placement goal | Run a requested number of replicas | Run one Pod on each eligible node |
| Primary use | Application workloads | Node-level agents |
| New node added | No automatic Pod specifically for that node | A Pod is created on the eligible node |
| Node removed | Replica may be placed elsewhere | Pod for that node disappears |
| Scaling | Change replica count | Change node eligibility |
| Horizontal Pod Autoscaler | Supported | Not supported |
| Typical examples | Web applications, APIs | Log collectors, monitoring agents |
How Deployment and DaemonSet Differ
The core question differs between the two controllers:
- Deployment asks: how many application replicas should run?
- DaemonSet asks: on which nodes must this agent run?
A three-replica web Deployment stays at three Pods when the cluster grows from three nodes to four. A logging DaemonSet on four eligible nodes runs four Pods — one per node. The Deployment count is application-driven; the DaemonSet count follows eligible nodes.
Deployment
A Deployment manages a specified number of interchangeable Pods through ReplicaSets.
- You declare
spec.replicasand a Pod template; the controller keeps that count running - The scheduler places Pods on suitable nodes according to resources and scheduling rules
- Rolling updates and rollback are supported through revision history
- Pod count stays independent of how many nodes exist in the cluster
Full apply, scale, rollout, and rollback workflows live in Deployments and rolling updates.
DaemonSet
A DaemonSet runs one Pod on every eligible node.
- When a matching eligible node joins, the controller creates a Pod on it
- When an eligible node is removed, its DaemonSet Pod is deleted
- Node selectors, affinity, taints, and tolerations determine which nodes count as eligible
- The controller is intended primarily for node-level services rather than interchangeable app tiers
YAML, verification, nodeSelector, tolerations, and rollout demos are covered in Kubernetes DaemonSet with Examples.
Pod Placement Differences
Deployment placement
The scheduler places the requested replicas on nodes that satisfy resource requirements, taints, affinity, and other scheduling rules. A Deployment does not normally guarantee one Pod on every node. Two replicas can land on the same node while another node runs none, unless you add topology spread or anti-affinity rules outside this comparison.
DaemonSet placement
A DaemonSet normally maintains one Pod per eligible node. During a rolling update, maxSurge can temporarily create an additional Pod on some nodes. Node labels, nodeSelector, affinity, and tolerations can limit which nodes qualify — for example, monitoring agents only on worker nodes. Configuration detail belongs in the DaemonSet tutorial; here the distinction is per-node coverage versus replica count.
Scaling Differences
Scale a Deployment
Increase or decrease spec.replicas when you need more or fewer application instances. The controller adds or removes Pods to match the number you set. You can also attach a Horizontal Pod Autoscaler to scale replica count from metrics such as CPU or memory utilization.
Scale a DaemonSet
DaemonSets do not have a replica count field and cannot be HPA targets — their count is node-driven rather than replica-driven. Pod count changes when:
- nodes are added or removed from the cluster
- node labels change eligibility
- you change
nodeSelector, affinity, or tolerations on the Pod template - a node gains or loses a taint that changes whether the DaemonSet Pod is eligible
Some standard taints are automatically tolerated by DaemonSet Pods, so merely adding any taint does not necessarily change the Pod count.
Adding a worker node can increase DaemonSet DESIRED without any manifest edit.
Update Behaviour
Both resources support rolling updates, but the replacement pattern and available strategies differ.
Deployments support RollingUpdate, which is the default, and Recreate. DaemonSets support RollingUpdate, also the default, and OnDelete. With OnDelete, updating the Pod template does not replace existing Pods until those Pods are manually deleted.
- Deployment updates replace interchangeable replicas across the cluster through ReplicaSets
- DaemonSet updates replace node-specific Pods on each eligible node
- DaemonSet rollout progress can stall when a node lacks resources, the image cannot be pulled, or the replacement Pod does not become ready
Rollout commands and tuning fields belong in the controller-specific guides — not repeated here.
When to Use Each Controller
Deployment
Choose a Deployment when:
- the workload is a web application, REST API, frontend, or stateless backend service
- you need a fixed or scalable number of interchangeable replicas
- any ready replica can serve traffic
- Pod count should not track node count automatically
Deployments are the default for long-running application tiers.
DaemonSet
Choose a DaemonSet when:
- a log collection, monitoring, networking, storage, or security agent must run on every eligible node
- adding a node should automatically start another instance of the agent
- the workload is tied to node identity rather than a requested replica count
DaemonSets fit infrastructure agents; application replicas normally belong in a Deployment.
Common Selection Scenarios
| Scenario | Recommended resource | Reason |
|---|---|---|
| Run five replicas of an API | Deployment | Replica count is application-driven |
| Run a log collector on every node | DaemonSet | One agent is needed per node |
| Run a monitoring exporter only on worker nodes | DaemonSet | Placement follows eligible nodes |
| Keep a web application available during updates | Deployment | Replicas and rollout are managed |
| Run one node-local instance on every eligible node | DaemonSet | Workload identity and count follow nodes |
| Spread interchangeable application replicas across nodes | Deployment | Use topology spread constraints or Pod anti-affinity |
| Run a scheduled cleanup task | Neither | Use a CronJob |
Common Misunderstandings
A Deployment with many replicas is not a DaemonSet
Even when spec.replicas equals the node count, Kubernetes does not guarantee one Deployment Pod per node. The scheduler may place multiple replicas on one node and leave another empty unless you add spread or anti-affinity constraints.
A DaemonSet is not scaled using spec.replicas
Desired Pod count is calculated from eligible nodes. You change coverage by changing nodes, labels, selectors, or tolerations — not a replica field.
DaemonSets are not only for system namespaces
DaemonSets commonly run in kube-system or platform namespaces, but they can run in application namespaces too. The pattern is node-level agents, not a namespace restriction.
A DaemonSet does not automatically run on every possible node
Control-plane taints, nodeSelector, affinity, and missing tolerations can exclude nodes. DESIRED reflects eligible nodes, not total cluster nodes.
Choose Deployment or DaemonSet
Walk through this sequence when you are unsure:
- Must one Pod run on every eligible node?
- Yes → DaemonSet
- Should adding a node automatically add another Pod?
- Yes → DaemonSet
- Is the desired Pod count independent of node count?
- Yes → Deployment
- Are the Pods interchangeable application replicas?
- Yes → Deployment
- Is the workload a node-level agent?
- Usually → DaemonSet
If you still need the wider controller map — StatefulSet, Job, CronJob, bare Pod — use choose a Kubernetes workload resource.
What's Next
- Kubernetes Init Containers with Examples
- Kubernetes Sidecar and Multi-Container Patterns with Examples
- Kubernetes Jobs with Examples
References
- Deployments
- DaemonSet
- Horizontal Pod Autoscaling
- Perform a Rolling Update on a DaemonSet
- Assign Pods to Nodes
Summary
Use a Deployment when you need a fixed or automatically scalable number of interchangeable application replicas. Use a DaemonSet when every eligible node needs its own node-local Pod. A Deployment replica count does not follow cluster size, while a DaemonSet automatically adds or removes Pods as eligible nodes join or leave.
