Sidecars

In this lesson we’ll review the Kubernetes sidecar pattern and how it fits into service meshes such as Istio. Understanding sidecars clarifies how proxies, log forwarders, and other support processes integrate with application containers without changing application code.

What is a sidecar?

The term derives from the motorcycle sidecar: an auxiliary unit attached to the main vehicle. In Kubernetes, a Pod can include one or more auxiliary containers alongside the main application container — these are called sidecars (or sidecar containers).
Sidecars separate cross-cutting concerns (logging, metrics, proxying, configuration, etc.) from the business logic implemented in the main container.

Key properties of sidecars in Kubernetes

Property	What it means
Networking namespace	Containers in the same Pod share the same network namespace and Pod IP, so they can communicate over `localhost` and share ports on that Pod IP.
Shared storage	Containers can mount the same volumes, letting a sidecar read files (for example, logs) written by the main container.
Process isolation	Containers run as separate processes inside the Pod, so failures are isolated but lifecycle is coupled at the Pod level.
Lifecycle	Pods are the unit of lifecycle: restarting a Pod restarts all containers in it. Individual containers may crash and be restarted separately, but they still belong to the same Pod.
Typical responsibilities	Sidecars handle cross-cutting concerns such as logging, metrics, configuration/file loading, or proxying (mTLS, routing, telemetry).

Common use cases for sidecars

Log forwarding and collection (Fluentd, Filebeat)
Service proxies and filters (Envoy in a service mesh)
Configuration or secrets synchronization
Local caches, adapters, or translators that present a stable interface to the app

Sidecars are central to service meshes: for example, Istio commonly injects an Envoy proxy as a per-Pod sidecar to provide traffic control, mutual TLS, routing, and telemetry without modifying application binaries. Example: main container + Fluentd sidecar Below is a simple Pod manifest showing an NGINX main container with a Fluentd sidecar that reads log files from a shared volume and forwards them to a central log endpoint.

apiVersion: v1
kind: Pod
metadata:
  name: nginx-with-fluentd
  labels:
    app: nginx
spec:
  containers:
    - name: nginx
      image: nginx:1.21
      ports:
        - containerPort: 80
      volumeMounts:
        - name: nginx-logs
          mountPath: /var/log/nginx
    - name: fluentd
      image: fluent/fluentd:latest
      env:
        - name: FLUENTD_ARGS
          value: "-q"
      volumeMounts:
        - name: nginx-logs
          mountPath: /var/log/nginx
  volumes:
    - name: nginx-logs
      emptyDir: {}

Manifest explanation

nginx is the primary application container and writes logs to /var/log/nginx.
fluentd is a sidecar container that mounts the same nginx-logs volume and forwards log data.
emptyDir is used for example purposes; in production you would typically use a durable volume or stream logs directly to a logging backend.
Because both containers share the Pod network and storage, Fluentd can read files directly and communicate locally if needed.

Containers in a Pod share networking and storage, but they run as separate processes. Sidecars are a useful way to separate operational concerns (logs, metrics, proxying) from application code without changing the app itself.

A note about service meshes and Envoy

In a service mesh such as Istio, an Envoy proxy sidecar is injected into application Pods (either automatically or via mutation webhook). The Envoy sidecar intercepts and manages inbound and outbound traffic for the app, providing mTLS, retries, observability, and traffic shaping with no change to the application.
Sidecar injection can be manual (add the container to manifests) or automatic (Istio mutating webhook). Automatic injection simplifies adoption but requires cluster-level configuration.

Remember: Pods are the lifecycle unit. If a Pod is deleted or restarted, all containers (application and sidecars) are affected. Design sidecars and storage choices (e.g., persistent volumes) with this in mind.

Introduction

Kubernetes Fundamentals

Kubernetes Resources

Scheduling

Container Orchestration - Security

Container Orchestration - Networking

Container Orchestration - Service Mesh

Container Orchestration - Storage

Cloud Native Architecture

Cloud Native Observability

Cloud Native Application Delivery

Conclusion

Watch Video