DaemonSets

Learn DaemonSets for running one Pod per node for agents, log collectors, networking, monitoring, and security tooling.

Last reviewed: June 2026

·Kubernetes 1.28+kubectl 1.28+Helm 3+Managed Kubernetes: EKS, AKS, GKE
✅
Quick Understanding: A DaemonSet ensures a copy of a Pod runs on each selected node.

🔍 What Is It?

A DaemonSet is a workload controller for node-level agents.

It is commonly used for logging agents, monitoring agents, CNI components, security scanners, and storage plugins.

🎯 Why Do We Need It?

Some workloads must run on every node or every node in a selected group to collect logs, expose metrics, enforce policy, or provide infrastructure functions.

Common developer mistakes:

  • →Treating Kubernetes YAML as copy-paste configuration instead of production architecture
  • →Ignoring requests, limits, health probes, security context, and rollout behavior
  • →Debugging only the Pod while forgetting Services, DNS, NetworkPolicies, nodes, and admission controls
  • →Manually changing live objects without updating Git or infrastructure automation

🏗️ What Happens in Real Projects?

A platform team deploys a log collector DaemonSet across all worker nodes. Each Pod mounts host log directories, ships logs to a central platform, and runs with carefully reviewed permissions.

⚙️ How It Works

The DaemonSet controller creates Pods on matching nodes. When new nodes join, DaemonSet Pods are created there. Node selectors, affinity, tolerations, and taints determine placement.

💻 Example

DaemonSet placement — Node-wide log agent pattern.

text
Node joins cluster
  -> DaemonSet controller sees matching labels
  -> log-agent Pod starts on that node
  -> Pod reads host logs
  -> logs ship to central observability platform

Common agents:
  CNI, log collector, metrics agent, security agent

🤔 Common Confusions

❓ Is DaemonSet for scaling APIs?

No. Use Deployments for replicated application services.

❓ Does DaemonSet run on control-plane nodes?

Only if selectors/tolerations allow it and the platform permits it.

❓ Can DaemonSets be risky?

Yes. They often need node-level permissions, so security review matters.

🚨 Common Production Issues

**Privileged agents** increase node compromise risk.

**No tolerations** prevents agents from running on tainted nodes where needed.

**Resource-heavy agents** reduce workload capacity on every node.

**Bad DaemonSet rollout** affects the whole cluster quickly.

✅ Best Practices

Use least privilege for node agents

Set resource requests and limits

Use tolerations and node selectors intentionally

Roll out platform DaemonSets carefully

Monitor agent health per node

🏛️ Architect's Note

Senior Architect's Perspective

DaemonSets are platform infrastructure. One bad DaemonSet can impact every node, so treat them as high-blast-radius changes.

💬 Frequently Asked Questions

Interview: How would you explain DaemonSets in a real Kubernetes project?

DaemonSets should be explained through the workload it supports, the Kubernetes object relationships, the failure modes, the security controls, and how it is observed and rolled back in production.

Interview: What production mistake do developers commonly make with DaemonSets?

The common mistake is making the object work once, then skipping ownership, resource sizing, rollout safety, monitoring, least privilege, and recovery behavior.

🎯 Key Takeaways

1DaemonSets run Pods on selected nodes
2They are ideal for node agents
3Permissions and resources must be reviewed
4Rollout blast radius is cluster-wide

🎯 Practice this topic in interviews

↗ Where this topic fits

Sources

Sources / References

Use these Kubernetes references to verify the concept in official docs and continue into the most relevant SplashRide pages.

Related SplashRide pages