What Does DaemonSets Mean?
Also known as: DaemonSet, Kubernetes DaemonSet, CKA exam, CNCF, container orchestration
On This Page
Quick Definition
A DaemonSet is a tool in Kubernetes that makes sure a certain program runs on every computer in a cluster. If you add a new computer, the DaemonSet automatically starts the program on it. If a computer is removed, the DaemonSet stops the program there. It is used for tasks that need to be present on every machine, like collecting logs or monitoring health.
Must Know for Exams
The DaemonSet topic is explicitly listed in the CNCF CKA (Certified Kubernetes Administrator) exam curriculum under the category Workloads and Scheduling. Specifically, the CKA objectives include understanding and using DaemonSets to deploy workloads on all nodes. The exam expects you to be able to create a DaemonSet from a YAML file, update it, perform rolling updates, and troubleshoot when pods are not scheduled.
You may be asked to configure a DaemonSet to run only on nodes with a specific label. Another common task is to deploy a DaemonSet that tolerates taints so it runs on control plane nodes or other tainted nodes. The CKA is a hands-on exam.
You will be given a Kubernetes cluster via a terminal, and you must complete tasks without a GUI. Being comfortable with kubectl commands for DaemonSets is essential. You need to know how to view DaemonSets with kubectl get daemonsets, describe them, and check the status of their pods.
You also need to understand the rollout history and how to roll back a DaemonSet update. The CKAD (Certified Kubernetes Application Developer) exam also touches on DaemonSets, but the focus is on understanding the use case rather than administration. For the CKA, you must know the difference between a DaemonSet and a Deployment.
A Deployment is for stateless applications that can be scaled and distributed based on resource availability. A DaemonSet is for node-level infrastructure. This distinction is frequently tested.
You may be asked to choose the correct workload type for a given scenario. The CKA exam also tests your understanding of scheduling constraints. You may be asked to create a DaemonSet that uses node selectors, and then verify that pods run only on the intended nodes.
No equivalent exam from other vendors, like AWS or Azure, directly tests DaemonSets because it is a Kubernetes-specific concept. However, many cloud vendor Kubernetes services like Amazon EKS and Azure AKS use DaemonSets internally. For the CNCF certification path, this is a foundational topic.
Simple Meaning
Imagine you work for a large office building with many floors. On each floor, there are several rooms. You are responsible for making sure that every single room has a fire extinguisher mounted on the wall.
You cannot miss a single room, and if a new room is built, you must install a fire extinguisher there immediately. In this analogy, each room is a node in a Kubernetes cluster, and the fire extinguisher is the pod that your DaemonSet manages. A DaemonSet is like a very diligent safety inspector.
It continuously scans all the rooms and guarantees that every room has its fire extinguisher. If a room is demolished, the inspector takes the extinguisher away. This is exactly what a DaemonSet does in a Kubernetes cluster.
It ensures that a specific pod runs on every node. When you add a new node to the cluster, the DaemonSet automatically deploys the pod on it. When a node is removed, the DaemonSet cleans up the pod.
This is different from other Kubernetes workloads, like deployments, which spread pods across nodes based on resource availability. A DaemonSet does not care about load balancing. Its job is universal coverage.
This makes it ideal for system-level services that must run everywhere. For example, a log collector must be on every node to gather logs from all applications. A health monitoring agent must be on every node to report the status of that machine.
A security scanner must scan every node for vulnerabilities. In short, a DaemonSet is the way Kubernetes says every node needs this job done, no exceptions. It is a fundamental building block for cluster infrastructure.
Full Technical Definition
A DaemonSet is a Kubernetes workload API object that guarantees that a copy of a pod runs on all, or a defined subset, of nodes within a cluster. As nodes are added to the cluster, the DaemonSet automatically schedules the pod on the new node. As nodes are removed, those pods are garbage collected.
The DaemonSet controller, part of the Kubernetes controller manager, continuously watches the cluster for node changes and maintains the desired state. The specification of a DaemonSet includes a pod template, which defines the container images, ports, volumes, and other pod settings. It also includes a selector, which is used to identify which pods belong to the DaemonSet.
The DaemonSet uses the node selector, node affinity, and tolerations fields in the pod template to control which nodes the pods are scheduled on. By default, a DaemonSet places a pod on every node. You can restrict it to specific nodes using node selectors.
For example, you might only want a GPU monitoring daemon on nodes with GPU hardware. You can specify node labels like gpu=true in the pod template, and the DaemonSet will only schedule pods on nodes that match that label. Tolerations are critical for DaemonSets when dealing with tainted nodes.
If a node has a taint, pods that do not tolerate that taint will not be scheduled on it. A DaemonSet can include tolerations in its pod template to override this, ensuring the daemon runs even on tainted nodes. This is essential for node-level infrastructure pods, such as networking plugins like Calico or Flannel, which must run on every node regardless of taints.
The DaemonSet respects the pod lifecycle. If a pod fails, the DaemonSet restarts it on the same node. If a node fails, the DaemonSet does not reschedule the pod to another node, because the daemon is tied to that specific node.
The DaemonSet is part of the Kubernetes apps/v1 API group. It uses a deterministic naming convention for its pods, typically appending a random suffix to the DaemonSet name. Rollout updates are supported.
You can update the pod template, and the DaemonSet will systematically terminate old pods and create new ones on each node, respecting the update strategy you define, such as RollingUpdate or OnDelete. In CNCF ecosystem, DaemonSets are used by many cloud-native projects. For instance, Prometheus node exporters, Fluentd or Logstash for log collection, and metrics servers all use DaemonSets.
Understanding DaemonSets is crucial for the CNCF CKA exam because it tests your ability to deploy and manage cluster-level services.
Real-Life Example
Think about a large apartment building with a security guard desk in the lobby. The building manager decides that every floor must have a safety information poster near the elevator. You are the person responsible for this task.
You walk through the building, and on every floor, you place a poster. If the building adds a new floor, you go up there and put a poster. If a floor is closed for renovation, you remove the poster.
In this story, the building is the Kubernetes cluster, each floor is a node, and each poster is a pod managed by a DaemonSet. The building manager represents the DaemonSet controller. You, as the worker, are the DaemonSet itself.
You do not decide which floors get a poster based on how many people live on that floor. Every floor gets exactly one poster. Similarly, a DaemonSet does not spread pods based on load.
It gives one pod per node. Now imagine the building has a basement floor with a special door and a sign that says only authorized maintenance staff can enter. That is like a tainted node in Kubernetes.
To put a poster there, you need special permission. In Kubernetes, that permission is called a toleration. The DaemonSet can include a toleration so that its pod can run on tainted nodes.
This is exactly how networking daemons work in Kubernetes. They must run on every node, even on nodes that are reserved for system workloads. Another layer of the analogy: suppose the building manager decides that only floors that have a fire alarm system installed should get the poster.
This corresponds to a node selector. The DaemonSet can be configured to only place pods on nodes with a specific label, such as hasFireAlarm=true. This gives you fine control over which nodes run the daemon.
This real-life mapping shows why DaemonSets are indispensable for cluster operations.
Why This Term Matters
DaemonSets are a critical tool for any Kubernetes administrator because they handle the kind of background tasks that keep a cluster healthy and observable. In real IT work, you cannot manually install software on every node every time a new machine joins the cluster. Clusters can scale to hundreds or thousands of nodes.
A DaemonSet automates this. For example, consider log collection. Every application running on a node produces logs. If you do not have a log collector on every node, you will miss logs from applications on that node.
A DaemonSet running Fluentd ensures complete log coverage. Similarly, monitoring metrics from the node itself, like CPU, memory, and disk usage, must come from an agent on that node. The Kubernetes metrics server uses a DaemonSet.
Security is another area. A vulnerability scanner must scan every node. If a node is missed, an attacker could exploit a vulnerability on that node without being detected. DaemonSets ensure no node is left unmonitored.
Network plugins, like those implementing the Container Network Interface (CNI), also rely on DaemonSets. These plugins must run on every node to set up virtual network interfaces and routing rules. If a node does not have the CNI plugin pod, new containers on that node will have no network connectivity.
This would break applications. Therefore, a DaemonSet is the standard way to deploy CNI plugins. For system administrators, DaemonSets reduce operational overhead. You define the configuration once, and Kubernetes ensures it is applied everywhere.
This is a principle of declarative infrastructure. You describe the desired state, and the system works to achieve it. DaemonSets also support rolling updates, so you can update the daemon across the entire cluster without downtime.
Without DaemonSets, you would have to write complex scripts to manage node-level services. In production, DaemonSets are used for node problem detectors, kernel module loaders, and even custom hardware monitoring agents. Understanding DaemonSets is a fundamental skill for any Kubernetes practitioner.
How It Appears in Exam Questions
In the CKA exam, DaemonSet questions appear in several patterns. Scenario questions present a situation and ask you to perform an action. For example, you might be told that a cluster has a set of nodes labeled disk=ssd, and you must create a DaemonSet that runs a log collector on only those nodes.
You would need to write or modify a YAML file with a nodeSelector field. Another scenario could ask you to deploy a DaemonSet that runs a network plugin on all nodes, including the control plane node which has a taint. You must add the appropriate toleration to the pod template.
Configuration questions may ask you to update an existing DaemonSet. For example, you might need to change the container image to a newer version, then perform a rolling update. You would use kubectl edit daemonset or patch the DaemonSet and then monitor the rollout.
Troubleshooting questions are common. You might be given a DaemonSet that is not scheduling pods on certain nodes. You would need to describe the DaemonSet, check node labels, check taints, and look at pod events to diagnose the issue.
The exam may also ask about DaemonSet selectors. You might be told that a DaemonSet is not creating pods, and you need to verify that the selector in the spec matches the labels in the pod template. Architecture questions test your theoretical understanding.
For example, you may be asked why a DaemonSet is preferred over a Deployment for a node monitoring agent. The answer involves the fact that a DaemonSet ensures one pod per node, whereas a Deployment could schedule multiple pods on the same node and leave other nodes empty. Another common pattern is the rolling update strategy.
You might be asked to configure a DaemonSet to update one node at a time with a specified max surge or max unavailable. The CKA exam does not have multiple-choice questions for this topic; the hands-on tasks require you to implement the solution in a live cluster. Therefore, you must be able to write YAML and use kubectl fluently.
Understanding how DaemonSets interact with node affinity, tolerations, and resource limits is key.
Study cncf-cka
Test your understanding with exam-style practice questions.
Example Scenario
You are a Kubernetes administrator for a company that runs an e-commerce platform. The platform's architecture includes a recommendation engine that uses a custom GPU-accelerated model. Only two nodes in your cluster, node-gpu-1 and node-gpu-2, have GPU hardware.
You need to deploy a monitoring daemon that collects GPU temperature and memory usage from these specific nodes. You do not want this daemon running on any other node because they do not have GPU hardware. You decide to use a DaemonSet.
You first label the two GPU nodes with gpu-node=true. Then you create a DaemonSet YAML file. In the spec, you add a nodeSelector under the pod template that requires gpu-node=true.
You also include a container specification for the monitoring agent. When you apply this YAML to the cluster, the DaemonSet controller reads the configuration. It sees that there are two nodes with the label gpu-node=true.
It creates one pod on each of those nodes. The DaemonSet does not attempt to run the pod on any other node because those nodes do not match the selector. A few days later, the IT team adds a third GPU node, node-gpu-3.
You label it with gpu-node=true. Within seconds, the DaemonSet controller detects the new node and automatically schedules a pod on it. The monitoring daemon runs immediately. This scenario shows how DaemonSets with node selectors provide precise control over where node-level services run.
Without a DaemonSet, you would have to manually deploy and manage pods on each GPU node. If a GPU node crashes and is replaced, the DaemonSet ensures the monitoring pod returns automatically. This reduces operational burden and ensures consistent monitoring coverage.
Common Mistakes
Thinking a DaemonSet schedules pods based on resource availability like a Deployment
Deployments use a scheduler to distribute pods across nodes based on resource requests and limits. DaemonSets ignore the scheduler entirely for node selection. They use node selectors, affinity rules, and taints to determine placement. The DaemonSet controller directly schedules the pod on every matching node. Resource availability is only considered when the pod is created, but the decision of which node to use is predetermined.
Remember that DaemonSets are for node-level services, not for load-balanced applications. A DaemonSet gives you one pod per matching node, not a distribution of pods across nodes.
Forgetting to add tolerations to a DaemonSet when it needs to run on tainted nodes
Control plane nodes and some worker nodes often have taints to prevent regular workloads from running. If a DaemonSet does not include the corresponding toleration, its pods will not be scheduled on those nodes. This can cause critical services like network plugins or monitoring agents to be missing from those nodes, leading to cluster issues.
When you need a DaemonSet to run on all nodes, including control plane or specially tainted nodes, add a tolerations section to the pod template that matches the node taints. For example, tolerations for node-role.kubernetes.io/master:NoSchedule.
Using a DaemonSet for a stateful application that requires unique storage per instance
DaemonSet pods are ephemeral and tied to nodes. If a node fails, the pod is recreated on the same node when it comes back, but the pod does not automatically move to another node. StatefulSets are designed for stateful applications because they provide stable pod identities and persistent storage. Using a DaemonSet for a stateful workload can result in data loss if the node is permanently lost.
Use StatefulSets for applications that need stable network identities and persistent storage per pod. Reserve DaemonSets for stateless, node-level services that do not require persistent state.
Assuming that updating a DaemonSet's pod template immediately updates all pods
The DaemonSet controller will eventually update all pods to match the new template, but it does so according to the update strategy. If you use the RollingUpdate strategy, it updates pods one node at a time by default. If you use the OnDelete strategy, pods are only updated when you manually delete them. A direct edit does not immediately restart all pods.
To force an immediate update, you can either wait for the rolling update to complete, delete pods manually if using OnDelete, or change the update strategy to RollingUpdate with appropriate maxSurge and maxUnavailable settings.
Confusing DaemonSet selectors with label selectors in Deployments
In a DaemonSet, the selector is used to match pods that belong to the DaemonSet. It is immutable after creation. If you change the selector, the DaemonSet will not be able to match its existing pods, and it will create new ones. In Deployments, the selector works similarly, but the key difference is that DaemonSet pods are tied to nodes, and the selector must match the labels in the pod template exactly.
Always set the selector and the pod template labels together. Once a DaemonSet is created, never change the selector. If you need to change it, delete the DaemonSet and recreate it.
Exam Trap — Don't Get Fooled
An exam scenario asks you to deploy a DaemonSet that must run on exactly three specific nodes out of a ten-node cluster. You are given the node names but not their labels. Many candidates assume they can use the node name directly in the nodeSelector field.
First, label each of the three nodes with a common label, for example, kubectl label node node1 daemon-target=true. Then in the DaemonSet YAML, add a nodeSelector matching that label. The DaemonSet will then create pods only on nodes with that label.
Do not attempt to use nodeName in the DaemonSet spec, as it will not be respected by the DaemonSet controller.
Commonly Confused With
A Deployment is used for stateless applications that can be scaled up or down based on demand. It distributes pods across nodes according to resource availability and scheduling policies. A DaemonSet, in contrast, ensures exactly one pod runs on each node or a subset of nodes, regardless of resource usage. Deployments are for serving traffic; DaemonSets are for node-level infrastructure.
You use a Deployment for your web server, which needs to handle many requests. The scheduler picks nodes with free resources. You use a DaemonSet for a log collector, which must be on every node to collect all logs.
A StatefulSet is designed for stateful applications like databases that need stable network identities, persistent storage, and ordered deployment. A DaemonSet provides no persistent identity or storage. StatefulSet pods can be scheduled on any node, while DaemonSet pods are tied to specific nodes and do not move on node failure.
You use a StatefulSet for a MongoDB replica set where each pod has a unique hostname and persistent volume. You use a DaemonSet for a security scanner that must run on every node to check for vulnerabilities.
A ReplicaSet ensures a specified number of pod replicas are running at any time. It does not care about which nodes they run on. A DaemonSet ensures one pod per node, so the number of replicas equals the number of nodes matching the selection criteria. ReplicaSets are typically used by Deployments, not for node-level services.
You use a ReplicaSet to maintain three replicas of an API server. You use a DaemonSet to run a node problem detector on every node.
Step-by-Step Breakdown
Define the DaemonSet YAML
Start by creating a YAML file with apiVersion: apps/v1, kind: DaemonSet, and metadata with a name. Under spec, you include a selector that matches labels in the pod template. The pod template itself contains containers, volumes, and other pod settings. This YAML is the blueprint for the DaemonSet.
Specify node targeting
Within the pod template, you can add nodeSelector, nodeAffinity, or tolerations. nodeSelector uses simple key-value label matching. nodeAffinity offers more complex expressions. Tolerations allow the pod to run on tainted nodes. This step determines which nodes will run the daemon pod.
Apply the DaemonSet to the cluster
Use kubectl apply -f daemonset.yaml to submit the configuration to the Kubernetes API server. The DaemonSet controller in the controller manager picks up the new resource. It reads the node targeting rules and begins creating pods on each matching node.
Pod creation on each matching node
For each node that matches the node targeting rules, the controller creates a pod. The pod is scheduled directly on that node, bypassing the default scheduler. The controller uses the node name to bind the pod. If the node is added later, the controller automatically creates a new pod on it.
Monitor and manage the DaemonSet
Use kubectl get daemonsets and kubectl describe daemonset to check the status. You can see how many nodes are currently scheduled with pods, how many are ready, and how many are up to date. If a pod fails, the controller recreates it on the same node. If a node is removed, the corresponding pod is deleted.
Update the DaemonSet
You can update the pod template by editing the DaemonSet. The update strategy (RollingUpdate or OnDelete) controls how the rollout proceeds. With RollingUpdate, pods are updated gradually, respecting maxUnavailable and maxSurge settings. This ensures minimal disruption to node-level services.
Roll back if necessary
If an update causes issues, you can roll back the DaemonSet to a previous revision using kubectl rollout undo daemonset. This restores the previous pod template and systematically reverts the pods on each node. The DaemonSet maintains rollout history for this purpose.
Practical Mini-Lesson
A DaemonSet is one of the core workload resources in Kubernetes, and mastering it is essential for any cluster administrator. In practice, you will rarely write a DaemonSet from scratch for an application. Instead, you will use DaemonSets provided by the ecosystem, such as those from the Kubernetes metrics server, Prometheus node exporter, Fluentd, or Calico.
However, you must understand how to customize them. For instance, when you install the metrics server, it typically creates a DaemonSet. You might need to modify its tolerations so it can run on control plane nodes.
To do this, you would edit the DaemonSet YAML and add a tolerations section. Understanding how node selectors work is crucial. You might have a heterogeneous cluster with some nodes equipped with GPUs, some with SSDs, and some with standard disks.
You can label these nodes accordingly, and deploy different DaemonSets to each group. For example, a GPU monitoring DaemonSet applies only to GPU nodes. Another DaemonSet for disk health monitoring applies only to nodes with SSDs.
This is a common pattern in large clusters. Another practical aspect is resource management. DaemonSet pods consume resources on every node. If you set resource requests too high, you might leave insufficient resources for application pods.
You must carefully tune resource requests and limits for daemon pods. For example, a log collector should ask for only the CPU and memory it genuinely needs. You can also configure priority classes for daemon pods to ensure they are not evicted during resource pressure.
Troubleshooting DaemonSets is a frequent task. If a DaemonSet pod is not running on a node, first check the DaemonSet status with kubectl describe daemonset. Look at the events section.
Common issues include the node not matching the selector, the node having a taint that is not tolerated, or the pod image not being available on that node. Also verify that the node is ready and not cordoned. If a DaemonSet appears to be running but the pod is not ready, use kubectl describe pod to see the container status.
For rolling updates, you can control the speed of the update. Setting maxUnavailable to 1 means that only one node at a time will have its daemon pod updated. This reduces risk. You can also use updateStrategy: RollingUpdate with a surge to allow new pods to start before old ones are terminated, but this consumes extra resources.
In production, this must be balanced with resource capacity. DaemonSets are also relevant for security. You can use Pod Security Policies or admission controllers to enforce that DaemonSet pods run with privileged access if needed, but this must be carefully controlled.
Finally, remember that DaemonSets are immutable in their selector. Plan your labels carefully before deployment. If you need to change the set of nodes, it is often easier to create a new DaemonSet and delete the old one than to change the selector.
Memory Tip
Think D-SET: DaemonSet Ensures one pod per noTe. The D stands for Daemon, S for Set, E for Ensures, T for per noTe. This helps recall that a DaemonSet guarantees coverage on every matching node, not load-based distribution.
Covered in These Exams
Related Glossary Terms
An A record is a DNS record that maps a domain name to the IPv4 address of the server hosting that domain.
802.1Q is the networking standard that allows multiple virtual LANs (VLANs) to share a single physical network link by tagging Ethernet frames with VLAN identification information.
802.1X is a network access control standard that authenticates devices before they are allowed to connect to a wired or wireless network.
Frequently Asked Questions
Can a DaemonSet run a pod on a node that is cordoned or drained?
No. If a node is cordoned (unschedulable), the DaemonSet controller will not create or reschedule pods on it. New pods will not be placed on a cordoned node. Existing pods may be evicted during a drain, and the DaemonSet will recreate them only after the node is made schedulable again.
What happens if a DaemonSet pod crashes?
The DaemonSet controller detects the pod failure and recreates the pod on the same node. It does not move the pod to another node, because the DaemonSet is designed to run on a specific node. The new pod will have a new name but the same configuration.
Can a DaemonSet be scaled manually?
No. A DaemonSet does not have a spec.replicas field. The number of pods is determined by the number of nodes that match the node selector. You cannot manually scale a DaemonSet. To change the number of pods, you must change the node labels or add/remove nodes.
Is it possible to run multiple DaemonSets on the same node?
Yes. Multiple DaemonSets can run pods on the same node, as long as they have different names and pod templates. For example, a monitoring DaemonSet and a logging DaemonSet can both run on all nodes. They are independent of each other.
How do I update a DaemonSet without downtime?
Use the RollingUpdate strategy with appropriate maxUnavailable and maxSurge settings. Set maxUnavailable to 1 to update one node at a time. If your cluster can handle extra pods, you can set maxSurge to 1 to create a new pod before terminating the old one on each node. This avoids service interruption.
What is the difference between a DaemonSet and a static pod?
A static pod is managed directly by the kubelet on a specific node, without the Kubernetes API server. Static pods are defined on disk on the node. A DaemonSet is managed by the API server and the controller manager, providing centralized control and rolling updates. DaemonSets are the preferred way for cluster-level services.
Can a DaemonSet use persistent volumes?
Yes, a DaemonSet pod can use persistent volumes, but it is unusual. Since DaemonSet pods are tied to nodes, a persistent volume that is ReadWriteOnce can only be attached to one pod at a time. This might be acceptable for node-specific data, but typically DaemonSets are stateless.
Summary
A DaemonSet is a Kubernetes resource that guarantees a specific pod runs on every node in a cluster, or on a subset of nodes defined by labels and tolerations. It is fundamental for node-level infrastructure services such as log collection, monitoring, networking, and security scanning. Unlike Deployments and StatefulSets, DaemonSets are not concerned with load balancing or scaling based on demand.
Instead, they ensure complete coverage of nodes. For the CKA exam, you must be able to create, update, and troubleshoot DaemonSets, understand scheduling constraints like node selectors and tolerations, and differentiate them from other workload types. In real-world IT, DaemonSets reduce manual effort and ensure consistency across the cluster.
By mastering DaemonSets, you gain control over the foundational services that keep a Kubernetes cluster healthy and operational. They are a prime example of Kubernetes' declarative model, where you specify the desired state and the system maintains it automatically.