AKS 5 – What is a Sidecar Container?

A Sidecar container is a helper container that runs alongside your main application container in the same Pod and helps it do its job.

Think of your application as a car, and the sidecar is like a co-driver or a support vehicle — it’s not the driver, but helps with navigation, music, tools, or repairs.

Imagine This:

You have a coffee machine (your main app) in a shop. Next to it, you place:

• A cleaning robot that keeps the machine clean.
• A printer that prints receipts.
• A camera that records customer visits.

These helpers don’t serve coffee, but they support the coffee machine.

Why Use a Sidecar?

A Sidecar container is used to:

• Monitor your app (e.g., log collection)
• Update configs or certificates dynamically
• Proxy traffic (e.g., Envoy or Istio sidecar)
• Backup data to a remote server
• Synchronize files or cache

Real-Life Examples:

1. Logging Agent
   App writes logs → Sidecar reads logs and sends to ELK or Grafana.
2. Envoy Proxy
   App sends requests → Sidecar Envoy container handles encryption or routing.
3. Database Backup
   Main app stores files → Sidecar regularly backs up data to S3.

Real-Life Analogy:

• Init Container = setting up a restaurant before opening (cleaning, placing tables, checking kitchen)
• Sidecar Container = staff working during service (waiter, music system, cashier)

Where DaemonSets Come In

• If you want every node in your cluster to run a log collector, you use a DaemonSet.
• Example: Deploying Fluent Bit as a DaemonSet means:
  • It runs on every node.
  • It collects logs from all pods on that node.
  • It can forward logs to Azure Monitor, Log Analytics, or other systems.

---

🔗 Combining Both Concepts

• Sidecar Container: Used when you want pod-specific logging, tightly coupled with the app. its kind is pod
• DaemonSet: Used when you want node-wide logging, collecting logs from all pods on the node. its kind is Daemon set

Sidecar container always available and check all things like logs and all.

If we enable restart policy in init container then it can work like sidecar container.

📄 Example Use Case:

Let’s say your app writes logs to a file. A sidecar container can:

• Read those logs.
• Forward them to a logging system (like Fluent Bit or Elasticsearch).

apiVersion: v1

kind: Pod

metadata:

  name: sidecar-demo

spec:

  containers:

  – name: main-app

    image: busybox

    command: [‘sh’, ‘-c’, ‘echo Hello from main app > /shared/log.txt && sleep 3600’]

    volumeMounts:

    – name: shared-data

      mountPath: /shared

  – name: log-forwarder

    image: busybox

    command: [‘sh’, ‘-c’, ‘tail -f /shared/log.txt’]

    volumeMounts:

    – name: shared-data

      mountPath: /shared

  volumes:

  – name: shared-data

    emptyDir: {}

What Happens Here:

• Main app writes logs to /shared/log.txt.
• Sidecar container reads and prints those logs.