Both Sidecars and DaemonSets are Kubernetes patterns for running supporting workloads, but they operate at different scopes and solve different problems.

1. Overview

• Sidecar: Extends the functionality of a single application Pod.
• DaemonSet: Runs an infrastructure service on every Kubernetes node.

A good rule of thumb is:

If the helper belongs to an application Pod, use a Sidecar. If it belongs to the Kubernetes infrastructure, use a DaemonSet.

2. Sidecar

What is a Sidecar?

A sidecar is an additional container that runs inside the same Pod as the main application.

Since they are in the same Pod, they:

• Share the same network namespace (localhost)
• Can share volumes
• Start and stop together
• Are scheduled together
• Share the same lifecycle

Pod
+------------------------------------------------+
|                                                |
|  +----------------+    +-------------------+   |
|  | Application    |    | Sidecar          |   |
|  | Container      |    | Container        |   |
|  +----------------+    +-------------------+   |
|                                                |
+------------------------------------------------+

Communication

Containers in the same Pod communicate through localhost.

Application
      │
      │ localhost
      ▼
Sidecar

They may also exchange files through shared volumes.

Common Use Cases

• Service Mesh Proxy (Istio Envoy)
• OAuth / Authentication Proxy
• Configuration Reloader
• Secret Injection
• Local Cache
• Metrics Exporter
• Request Logging

Example: Istio Service Mesh

Each application Pod receives its own Envoy proxy.

Pod

+----------------+
| Application    |
+----------------+
        │
 localhost
        ▼
+----------------+
| Envoy Sidecar  |
+----------------+
        │
        ▼
 Other Services

All incoming and outgoing traffic passes through the Envoy sidecar.

Advantages

• Tight integration with the application
• Very fast communication via localhost
• Can share storage
• Independent implementation language
• Reusable infrastructure logic

Disadvantages

• Additional CPU and memory for every Pod
• Slower Pod startup
• Resource usage scales with the number of Pods

Example:

100 Application Pods
→ 100 Sidecars

3. DaemonSet

What is a DaemonSet?

A DaemonSet is a Kubernetes controller that ensures one Pod runs on every node (or selected nodes).

Unlike a Sidecar, a DaemonSet Pod is completely independent of application Pods.

Cluster

Node A
 ├── Application
 ├── Application
 └── DaemonSet Pod

Node B
 ├── Application
 └── DaemonSet Pod

Node C
 ├── Application
 └── DaemonSet Pod

When a new node joins the cluster, Kubernetes automatically schedules another DaemonSet Pod.

Common Use Cases

• Log collection
• Node monitoring
• Network plugins
• Storage plugins
• Security agents

Typical examples:

• Fluent Bit
• Node Exporter
• Cilium
• Calico
• CSI Driver
• Falco

4. Real-World DaemonSet Examples

4.1. Fluent Bit (Log Collection)

Purpose

Collect logs from every container running on a node.

Without Fluent Bit:

Application
    │
stdout
    │
Node

Logs remain on the node and are difficult to search across the cluster.

With Fluent Bit:

Node

App1
App2
App3
 │
 ▼
Fluent Bit
 │
 ▼
Loki / Elasticsearch
 │
 ▼
Grafana

Fluent Bit:

• Reads container logs from /var/log/containers
• Parses and enriches logs
• Sends logs to:
  • Grafana Loki
  • Elasticsearch
  • Splunk
  • Datadog
  • S3

Since one Fluent Bit instance can collect logs for every Pod on a node, it is deployed as a DaemonSet.

4.2. Node Exporter (Metrics Collection)

Purpose

Expose node-level metrics such as:

• CPU usage
• Memory usage
• Disk usage
• Network traffic
• Filesystem statistics

Architecture:

Node

CPU
Memory
Disk
Network

      │
      ▼
Node Exporter
      │
      ▼
Prometheus
      │
      ▼
Grafana

Prometheus periodically scrapes:

http://node-exporter:9100/metrics

Because every node requires monitoring, Node Exporter is deployed as a DaemonSet.

4.3. Cilium / Calico

These are Kubernetes networking plugins.

Node

Pods
 │
 ▼
Cilium Agent
 │
 ▼
Kubernetes Network

Each node requires exactly one networking agent.

Deployment:

DaemonSet

4.4. Falco

Falco monitors runtime security events.

Examples:

• Suspicious processes
• Privilege escalation
• Unexpected shell execution
• Container escape attempts

Node

Containers
     │
     ▼
 Falco
     │
     ▼
 Security Alerts

Falco monitors the entire node, so it runs as a DaemonSet.

5. Sidecar vs DaemonSet

6. Architecture Comparison

6.1. Sidecar

             Pod
+--------------------------------------+
|                                      |
|  +------------+   +---------------+  |
|  | App        |<->| Sidecar       |  |
|  +------------+   +---------------+  |
|                                      |
+--------------------------------------+

6.2. DaemonSet

              Kubernetes Cluster

+----------------+   +----------------+   +----------------+
| Node A         |   | Node B         |   | Node C         |
|                |   |                |   |                |
| App            |   | App            |   | App            |
| App            |   |                |   | App            |
|                |   |                |   |                |
| Fluent Bit     |   | Fluent Bit     |   | Fluent Bit     |
| Node Exporter  |   | Node Exporter  |   | Node Exporter  |
| Cilium         |   | Cilium         |   | Cilium         |
+----------------+   +----------------+   +----------------+