Skip to main content

Understanding DaemonSets: Floor Service on Every Floor

DaemonSets are like floor service on every hotel floor. One service per floor. System services. Node-level operations. That's DaemonSets.

🎯 The Big Picture​

Think of DaemonSets like floor service on every hotel floor. Every floor has floor service (every node has pod). System services. Node-level. That's DaemonSets.

DaemonSets ensure pod runs on every node. System services. Logging. Monitoring. Node agents. Essential for cluster operations.

The Floor Service Analogy​

Think of DaemonSets like floor service on every floor:

DaemonSet: Floor service system

  • Every floor has service
  • One service per floor
  • System services

Every node: Every floor

  • Pod on every node
  • Automatic placement
  • Node-level

System services: Floor services

  • Logging
  • Monitoring
  • Node agents
  • System operations

Once you see it this way, DaemonSets make perfect sense.

What is a DaemonSet?​

DaemonSet definition:

  • Ensures pod on every node
  • System services
  • Node-level operations
  • Automatic placement

Think of it as: Floor service. Every floor. System services.

Why DaemonSets?​

Problems without DaemonSets:

  • Manual pod placement
  • No system services
  • Missing node-level ops
  • Cluster issues

Solutions with DaemonSets:

  • Automatic placement
  • System services
  • Node-level operations
  • Cluster operations

Real example: I once ran logging manually. Some nodes missing. Incomplete logs. With DaemonSet, every node. Complete. Never going back.

DaemonSets aren't optional for system services. They're essential.

DaemonSet vs Deployment​

Comparison:

Deployment:

  • User applications
  • Specific replica count
  • Can scale
  • Application pods

DaemonSet:

  • System services
  • One per node
  • Auto-scales with nodes
  • System pods

Think of it as: Application rooms vs floor service. Different use. Different behavior.

Common Use Cases​

System services:

Logging:

  • Fluentd
  • Log collection
  • Every node

Monitoring:

  • Node exporter
  • Metrics collection
  • Every node

Networking:

  • CNI plugins
  • Network agents
  • Every node

Storage:

  • Storage agents
  • Volume management
  • Every node

Think of it as: Floor services. Logging. Monitoring. Networking. Storage.

Real-World Example: Logging DaemonSet​

Complete logging DaemonSet:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd
  namespace: kube-system
  labels:
    app: fluentd
spec:
  selector:
    matchLabels:
      app: fluentd
  template:
    metadata:
      labels:
        app: fluentd
    spec:
      containers:
      - name: fluentd
        image: fluent/fluentd:latest
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        - name: varlibdockercontainers
          mountPath: /var/lib/docker/containers
          readOnly: true
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      - name: varlibdockercontainers
        hostPath:
          path: /var/lib/docker/containers
      tolerations:
      - effect: NoSchedule
        operator: Exists

What this does:

  • Runs on every node
  • Collects logs
  • System service

That's a complete DaemonSet. Production-ready.

My Take: DaemonSet Strategy​

Here's what I do:

Use DaemonSets for:

  • Logging agents
  • Monitoring agents
  • Network plugins
  • System services

Use Deployments for:

  • User applications
  • Web servers
  • APIs
  • Applications

The key: DaemonSets for system services. Deployments for applications. Right tool.

Memory Tip: The Floor Service Analogy​

DaemonSets = Floor service on every floor

DaemonSet: Floor service system Every node: Every floor System services: Floor services

Once you see it this way, DaemonSets make perfect sense.

Common Mistakes​

  1. Using for applications: Wrong tool
  2. Not understanding placement: Confusion
  3. Missing tolerations: Can't run on tainted nodes
  4. Not using for system services: Missing functionality
  5. Confusing with Deployments: Wrong understanding

Key Takeaways​

  1. DaemonSets run on every node - One pod per node
  2. System services - Logging, monitoring, networking
  3. Automatic placement - No manual scheduling
  4. Use for system services - Not applications
  5. Essential for cluster ops - System functionality

What's Next?​

Now that you understand DaemonSets, let's learn about Jobs and CronJobs. Next: Understanding Jobs.

Remember: DaemonSets are like floor service on every floor. One per node. System services. Use for logging, monitoring, networking. Essential for cluster operations.