This article was last updated on February 6, 2025, to include advanced techniques for managing DaemonSets, such as handling updates, monitoring health, and implementing best practices for production environments, along with simplified explanations to enhance clarity.
What is a Kubernetes DaemonSet: A Complete Guide
What is a DaemonSet?
Think of a DaemonSet as a hotel housekeeping: one takes care of a single individual (pod) for each floor (node in your hotel (cluster). With a new floor added, a new housekeeping accompanies it, and when a floor is removed, its housekeeping accompanies it out.
Why use DaemonSets?
- Run a monitor agent in each node
- Collect logs for all nodes
- Ensure network plugins function anywhere
- Handle node-level maintenance tasks
Warning: DaemonSets will execute on ALL nodes, with default careful use of resources
I remember my first encounter with DaemonSets: I'd joined a new team working with a large Kubernetes cluster, and logging collection was an issue for them. We'd been deploying logging agents onto individual nodes (I know, I know, not my best work).
When a senior developer introduced me to DaemonSets, I'd discovered autopilot for a plane I'd flown for years with my hands firmly clutching onto controls
Steps we'll use
- What is a Kubernetes DaemonSet: A Complete Guide
- How DaemonSets Work: Understanding Pod Distribution
- How to Create Your First DaemonSet: Step-by-Step Guide
- How to Optimize DaemonSet Performance: Resource Management Guide
- How to Use Taints and Tolerations in DaemonSets
- How to Update DaemonSets: Rolling Update Strategy
- How to Configure DaemonSet Networking
- What are DaemonSet Alternatives: Other Kubernetes Solutions
- How to Use DaemonSets in Production: Best Practices
- Comparison Table: DaemonSets vs Alternatives
- Conclusion
How DaemonSets Work: Understanding Pod Distribution
Let me make DaemonSets easier to understand with a real-life scenario. Let's say I manage a collection of hotels. There must be one housekeeper (pod) for each hotel (node to service it). Opening a new hotel, I don't have to go out and hire a housekeeper, but it must happen automatically.
That is exactly what DaemonSets in Kubernetes do!
Try our daemonset simulator and see how they work:
Interactive DaemonSet Simulator
Explore how DaemonSets manage pods across your Kubernetes cluster. Add/remove nodes, apply taints, and see how DaemonSets automatically adjust to maintain the desired state.
How to Use:
- Click "Add Node" to add a new node to your cluster
- Click "×" to remove a node
- Click the checkmark/no-entry button to toggle node taints
- Click the status button to toggle node readiness
- Enable/disable tolerations to see how DaemonSets handle tainted nodes
- Watch how DaemonSet pods automatically adjust to cluster changes!
How to Create Your First DaemonSet: Step-by-Step Guide
Let me show you creating a simple DaemonSet. I have a simple template I use consistently:
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: monitoring-agent
namespace: monitoring
spec:
selector:
matchLabels:
app: monitoring-agent
template:
metadata:
labels:
app: monitoring-agent
spec:
containers:
- name: monitoring-agent
image: monitoring-agent:1.0
resources:
limits:
memory: 200Mi
cpu: 200m
requests:
memory: 100Mi
cpu: 100m
In this YAML, we're instructing Kubernetes: "I'd prefer one monitoring agent for each of my cluster's nodes." It's a lot like issuing your hotel management software an instruction to have one housekeeper for a single floor at any one time.
How to Optimize DaemonSet Performance: Resource Management Guide
One of the most difficult parts about working with DaemonSets is getting a balancing act between allowance and resources. I experienced it firsthand when our monitor DaemonSet took too much CPU and hurt performance in the cluster.
Here's how I organize my resources these days:
resources:
limits:
memory: "200Mi"
cpu: "100m"
requests:
memory: "100Mi"
cpu: "50m"
Think of it in terms of boundary-setting for your housecleaners: they need enough tools to work with, but not enough to fill your entire closet for storing them in.
How to Use Taints and Tolerations in DaemonSets
Sometimes you don't necessarily desire your DaemonSet pods to run on all your nodes. For example, you can have certain nodes not run monitor agents. That is when taints and toleration become involved.
tolerations:
- key: node-role.kubernetes.io/control-plane
operator: Exists
effect: NoSchedule
This is similar to stating "this housekeeping can run in the executive level" - it opens access to pods with no permission to execute in such a level.
How to Update DaemonSets: Rolling Update Strategy
Updating a DaemonSet is a lot like changing shifts for your maid service, not wanting to make a big fuss and cause an uproar in service. That's my update routine:
spec:
updateStrategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1
This ensures one pod at a time will be updated, with less impact to your cluster.
How to Configure DaemonSet Networking
DaemonSet pods will often have to communicate with other services in your cluster. I utilize these shared patterns:
What is Push Notification Model?
spec:
template:
spec:
containers:
- name: log-collector
env:
- name: CENTRAL_LOGGING_SERVICE
value: "logging-service.monitoring:8080"
How to Set Up Direct Node Access
spec:
template:
spec:
hostNetwork: true
containers:
- name: monitoring-agent
ports:
- containerPort: 8080
hostPort: 8080
What are DaemonSet Alternatives: Other Kubernetes Solutions
Sometimes a DaemonSet isn't necessarily well-used for a use case. There have been alternatives I have used:
- Static Pods: For when you need even more lifecycle management over pods
- Deployments with Node Affinity: For flexible scheduling
- Init Containers: For single-use nodestateful configuration
How to Use DaemonSets in Production: Best Practices
After years of working with Kubernetes, I utilize DaemonSets when:
- Monitoring Agents (for instance, Prometheus Node Exporter)
- Log collectors (for instance, Fluentd, Filebeat)
- Network plugins (for instance, Calico or Weave)
- Storage plugins (for instance, Ceph, GlusterFS)
Comparison Table: DaemonSets vs Alternatives
| Feature | DaemonSet | Deployment | StatefulSet | Static Pod |
|---|---|---|---|---|
| Purpose | Node-specific tasks | Scalable workloads | Stateful workloads | Node-specific tasks |
| Runs on all nodes | Yes | No | No | Yes |
| Use cases | Monitoring, logging | Apps, APIs | Databases, queues | Critical tasks |
| Scheduling flexibility | High | High | Medium | Low |
Conclusion
DaemonSets are such reliable cleaners for hotels - working in the background, unobtrusively, and getting everything tickety-boo. As powerful as they can become, use them cautiously and don't forget to monitor consumption at all times.
Remember: Start simple, test extensively, and monitor your use of resources at all times. Your future self (and your cluster) will appreciate it!