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.
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
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
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: true2. 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.
# 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-injected3. Secret Sidecar (Vault Agent)
HashiCorp Vault injects a sidecar that fetches secrets and writes them to a shared volume:
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 directly4. Git Sync Sidecar
Sync a git repo into a shared volume so the main app always has the latest config or content:
- 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: /gitInit Containers vs Sidecar Containers
Common confusion:
| Init Container | Sidecar Container | |
|---|---|---|
| When it runs | Before main container starts | Same time as main container |
| Lifecycle | Runs once, exits | Runs for the pod's lifetime |
| Purpose | Setup tasks (DB migration, wait for dependency) | Ongoing helper (logging, proxy, sync) |
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:latestNative Sidecar Support (Kubernetes 1.29+)
Kubernetes 1.29 added native sidecar support — sidecars defined under initContainers with restartPolicy: Always:
initContainers:
- name: log-collector
image: fluent-bit:latest
restartPolicy: Always # ← this makes it a native sidecarAdvantage: 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
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
Build a Kubernetes Cluster with kubeadm from Scratch (2026)
Step-by-step guide to building a real multi-node Kubernetes cluster using kubeadm — no managed services, no shortcuts.
How to Build a DevOps Home Lab for Free in 2026
You don't need expensive hardware to practice DevOps. Here's how to build a complete home lab with Kubernetes, CI/CD, and monitoring using free tools and cloud free tiers.
How to Crack the CKA Exam in 2026: Study Plan, Resources, and Tips
Complete CKA exam prep guide for 2026 — what to study, how to practice, which resources actually help, and tips to pass on the first attempt.