What is a sidecar container in a Kubernetes Pod?
A sidecar is a helper container running in the same Pod as the main app, sharing its network and volumes. Common uses are log shippers, proxies such as Envoy, and config reloaders.
Explain it simply
A motorcycle with a sidecar: the rider drives, the sidecar carries extra things, and both travel together. The main container serves requests while the sidecar supports it without changing its code.
Because containers in a Pod share localhost and volumes, a sidecar can read the log file the app writes to a shared emptyDir and ship it to a central system, or intercept traffic as a service-mesh proxy and add encryption and retries, or refresh credentials in a shared volume. The app stays simple and the helper can be reused across teams and updated independently of the app image.
Trade-offs: each sidecar uses CPU and memory in every replica, and the Pod is considered ready only when its containers are. Recent Kubernetes versions support native sidecars as init containers with restartPolicy: Always, which start before and stop after the main container.
Example
spec:
containers:
- name: app
image: myapp:1.0
volumeMounts: [{name: logs, mountPath: /var/log/app}]
- name: log-shipper
image: fluent/fluent-bit:3.0
volumeMounts: [{name: logs, mountPath: /var/log/app}]
volumes:
- name: logs
emptyDir: {}What to say in the interview
"A sidecar is a helper container in the same Pod, sharing network and volumes with the app, for tasks like log shipping, proxying or config reload. It keeps the app code simple at the cost of extra resources per replica."
Common mistakes
- Putting unrelated apps in one Pod; separate Pods let them scale independently.