🎉 DevOps Interview Prep Bundle is live — 1000+ Q&A across 20 topicsGet it →
All Articles

What is a Sidecar Container in Kubernetes? Explained Simply

A sidecar container runs alongside your main container in the same pod. Here's what it is, why it's useful, and real examples like log collectors, proxies, and secret injectors.

DevOpsBoysJun 11, 20263 min read
Share:Tweet

A sidecar container is a helper container that runs in the same pod as your main application container. They share the same network namespace and can share volumes — they're tightly coupled but separate processes.

The name comes from a motorcycle sidecar: the main container is the motorcycle, the sidecar is attached and travels alongside it.


How It Works

yaml
apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: main-app          # Your application
    image: my-app:1.0.0
    ports:
    - containerPort: 8080
  
  - name: log-collector     # Sidecar
    image: fluent-bit:latest
    volumeMounts:
    - name: logs
      mountPath: /var/log/app
  
  volumes:
  - name: logs
    emptyDir: {}

Both containers start together, run together, and stop together. The main app writes logs to /var/log/app, the sidecar reads from the same volume and ships them to Loki or Elasticsearch.


Why Use Sidecars?

The idea: keep your application code focused on business logic. Cross-cutting concerns (logging, metrics, security, proxying) go in the sidecar.

Benefits:

  • Main app doesn't need logging/metrics libraries — sidecar handles it
  • Sidecar can be updated independently (e.g., upgrade log collector without redeploying app)
  • Same sidecar works for any language/framework
  • Enforces separation of concerns at the infrastructure level

Real-World Sidecar Examples

1. Log Collector

yaml
containers:
- name: app
  image: my-app:latest
  # writes logs to /var/log/app/
 
- name: fluent-bit
  image: fluent/fluent-bit:latest
  # reads /var/log/app/, ships to Loki
  volumeMounts:
  - name: app-logs
    mountPath: /var/log/app
    readOnly: true

2. Service Mesh Proxy (Istio/Linkerd)

This is the most common sidecar in production. Istio automatically injects an Envoy proxy sidecar into every pod:

Request → Envoy sidecar → main app
Response ← Envoy sidecar ← main app

The Envoy proxy handles mTLS, traffic policies, retries, circuit breaking — all without any code changes to the main app. The app doesn't know the proxy is there.

bash
# Check injected sidecars in an Istio mesh
kubectl get pod my-app -o jsonpath='{.spec.containers[*].name}'
# Output: my-app istio-proxy   ← the sidecar was auto-injected

3. Secret Sidecar (Vault Agent)

HashiCorp Vault injects a sidecar that fetches secrets and writes them to a shared volume:

yaml
annotations:
  vault.hashicorp.com/agent-inject: "true"
  vault.hashicorp.com/agent-inject-secret-db-password: "secret/data/db"
  vault.hashicorp.com/role: "my-app"
 
# Vault agent sidecar writes /vault/secrets/db-password
# Main app reads from that file — never touches Vault API directly

4. Git Sync Sidecar

Sync a git repo into a shared volume so the main app always has the latest config or content:

yaml
- name: git-sync
  image: registry.k8s.io/git-sync/git-sync:v4.2.1
  args:
  - --repo=https://github.com/org/config-repo
  - --branch=main
  - --period=60s
  - --root=/git
  volumeMounts:
  - name: config
    mountPath: /git

Init Containers vs Sidecar Containers

Common confusion:

Init ContainerSidecar Container
When it runsBefore main container startsSame time as main container
LifecycleRuns once, exitsRuns for the pod's lifetime
PurposeSetup tasks (DB migration, wait for dependency)Ongoing helper (logging, proxy, sync)
yaml
spec:
  initContainers:
  - name: wait-for-db        # runs first, exits when done
    image: busybox
    command: ['sh', '-c', 'until nc -z db 5432; do sleep 2; done']
  
  containers:
  - name: app                # starts after init container exits
    image: my-app:latest
  - name: log-collector      # starts at same time as app, runs alongside it
    image: fluent-bit:latest

Native Sidecar Support (Kubernetes 1.29+)

Kubernetes 1.29 added native sidecar support — sidecars defined under initContainers with restartPolicy: Always:

yaml
initContainers:
- name: log-collector
  image: fluent-bit:latest
  restartPolicy: Always    # ← this makes it a native sidecar

Advantage: native sidecars start before the main container and stop after it — solves the ordering problem where the sidecar would die before flushing final logs.

Learn Kubernetes pod architecture and patterns at KodeKloud.

🔧

Today I Fixed

Short real fixes from production — posted daily

Browse fixes
Newsletter

Stay ahead of the curve

Get the latest DevOps, Kubernetes, AWS, and AI/ML guides delivered straight to your inbox. No spam — just practical engineering content.

Related Articles

Comments