Multi-container pods in Kubernetes: Sidecar, ambassador and adapter patterns

A pod can run more than one container. All containers in the same pod share the same network namespace and can share volumes. This tight coupling is what makes multi-container pods useful for a specific set of patterns where two processes need to work together closely.

The three patterns

Sidecar

A sidecar container enhances or supports the main container without changing it. The main container does its job and the sidecar handles a secondary concern alongside it.

Real-world uses: a Fluentd or Filebeat sidecar reads application logs from a shared emptyDir volume and ships them to Elasticsearch. An Envoy sidecar injected by Istio handles mTLS, retries, and traffic management transparently. A git-sync sidecar continuously pulls configuration updates from a Git repository into a shared volume that the main container reads.

Ambassador

An ambassador container acts as a proxy between the main container and an external service. The main container always connects to localhost and the ambassador handles the real routing.

Real-world use: a Redis proxy ambassador handles connection pooling and routing to the correct Redis instance in a cluster. The main application always connects to localhost:6379 regardless of the Redis topology behind it. If the topology changes, only the ambassador needs updating.

Adapter

An adapter container normalises the main container's output into a standard format that an external system expects, without modifying the main container itself.

Real-world use: an adapter converts proprietary application metrics into the Prometheus exposition format. Prometheus scrapes the adapter, not the main application. The main application does not need to know about Prometheus at all.

How containers in the same pod communicate

Containers in the same pod share a network namespace. They share the same IP address and port space. A container listening on port 8080 can be reached by any other container in the same pod at localhost:8080. No service or ingress is needed for intra-pod communication.

They can also share data by mounting the same volume at different paths.

Working example: sidecar pattern

This example is the sidecar pattern. An Alpine container writes the current date and memory information to index.html on a shared emptyDir volume every few seconds. An nginx container reads from that same volume and serves the file.

1apiVersion: v1
2kind: Pod
3metadata:
4  name: multi-container
5spec:
6  volumes:
7  - name: shared-data
8    emptyDir: {}
9  containers:
10  - name: nginx-container
11    image: nginx
12    volumeMounts:
13    - mountPath: /usr/share/nginx/html
14      name: shared-data
15  - name: alpine-container
16    image: alpine
17    command:
18    - sh
19    - -c
20    - while true; do date >> /mem-info/index.html; cat /proc/meminfo >> /mem-info/index.html; sleep 5; done
21    volumeMounts:
22    - mountPath: /mem-info
23      name: shared-data

1kubectl apply -f multi-container.yaml
2kubectl get pods

Expected output:

1NAME              READY   STATUS    RESTARTS   AGE
2multi-container   2/2     Running   0          10s

2/2 confirms both containers are running. When a pod has multiple containers, you must specify which container you want logs from:

1kubectl logs -f multi-container -c nginx-container

Exec into the nginx container:

1kubectl exec -it multi-container -c nginx-container -- sh

Curl localhost to see the content being written by the Alpine container:

1curl localhost

Expected output — date and memory info appended by the Alpine sidecar and served by nginx:

1Thu Jan 15 10:23:01 UTC 2026
2MemTotal:       16384000 kB
3MemFree:         8192000 kB
4...

Run curl localhost again after a few seconds and you will see a new timestamp appended. Data is being written by one container and read by the other through the shared emptyDir volume.

Exit the pod:

1exit