> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Sidecars

> Explains Kubernetes sidecar pattern where auxiliary containers handle logging, proxies, and shared storage/networking to enable service mesh features and separate operational concerns from application code.

In this lesson we'll review the Kubernetes sidecar pattern and how it fits into service meshes such as [Istio](https://learn.kodekloud.com/user/courses/istio-service-mesh). Understanding sidecars clarifies how proxies, log forwarders, and other support processes integrate with application containers without changing application code.

![A slide titled "Sidecars" featuring a white-and-blue icon of a motorcycle with a sidecar against a dark blue curved background. The corner shows a small © Copyright KodeKloud label.](https://mintcdn.com/kodekloud-c4ac6d9a/UK3oaG81L_yXeDcP/images/Kubernetes-and-Cloud-Native-Associate-KCNA/Container-Orchestration-Service-Mesh/Sidecars/sidecars-motorcycle-icon-blue-slide.jpg?fit=max\&auto=format\&n=UK3oaG81L_yXeDcP\&q=85\&s=c7bc9b787ef164dcc8c69501103bf5eb)

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](https://learn.kodekloud.com/user/courses/istio-service-mesh) 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.

```yaml theme={null}
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.

Further reading and references

* [Kubernetes Pods — official docs](https://kubernetes.io/docs/concepts/workloads/pods/)
* [Istio service mesh (KodeKloud course)](https://learn.kodekloud.com/user/courses/istio-service-mesh)
* [Envoy proxy official website](https://www.envoyproxy.io/)
* Best practices: design sidecars to be stateless where possible and avoid introducing single points of failure by relying on durable storage or external services for critical data.

> **[Watch Video](https://learn.kodekloud.com/user/courses/kubernetes-and-cloud-native-associate-kcna/module/aeecda11-7f2e-48c5-9c54-5409f2d9d8d8/lesson/106d7fcd-7678-46d8-832d-13b101581d2b)**


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.