Multi-Container Patterns in Kubernetes: Adapter, Ambassador, Sidecar

3 min readOct 5, 2023

A Kubernetes pod may contain several containers.

Init containers are one of the multi-container patterns: Kubernetes Core Concepts: Init Containers

Photo by DDP on Unsplash

Except for the init containers, the declaration syntax of all multi-container patterns in the YAML file is similar:

apiVersion: v1
kind: Pod
name: pod-name
- image: container-image1
name: container1
... (settings for container1)

- image: container-image2
name: container2
... (settings for container2)

The pattern names are derived from the secondary container’s function.

Adapter Container Pattern

The adapter container pattern’s main function is to manipulate the application’s output or logs.

The adapter container pattern has two major use-case scenarios:

● The existing application requires modifications in order to align with the desired output specifications of the client.

● You have application logs that lack timestamps, hostnames, and so on. You need to enrich the application logs

Ambassador Container Pattern

The term “ambassador container pattern” refers to the situation in which the secondary container functions as a proxy.

A few use-case scenarios for using the ambassador container pattern:

● You want to enable HTTP Basic Authentication for your application

● Let’s say the application (POD-1) runs on HTTP, and another pod (POD-2) wants to connect to it through HTTPS. In POD-1, you may use Nginx as a secondary container. The Nginx container will handle SSL/TLS requests and redirect secure traffic to the application.

● If there is no user agent, you might want to drop the connection. You can set up Nginx as a secondary container on the pod, and if the user agent header is missing, it will drop the connection.

Here’s an example configuration for the Ambassador Container Pattern


apiVersion: v1
kind: Service
name: adil-service
app: adil-pod
- protocol: TCP
port: 80
targetPort: 80
apiVersion: v1
kind: ConfigMap
name: nginx-config
reverse-proxy-drop-useragent: |
server {
listen 80;
server_name _;

if ($http_user_agent = "") { return 403; }

location / {
proxy_pass http://localhost:8080/;
proxy_set_header Host $http_host;

The file 00-init.yaml is responsible for creating the essential service that enables the ambassador container to be accessible, as well as storing the necessary Nginx configurations as a ConfigMap.

Please note that the Nginx configuration contains an if condition for the empty user agents.


apiVersion: v1
kind: Pod
name: adil-pod
app: adil-pod
- image: webratio/nodejs-http-server
name: web-container
- image: nginx:latest
name: ambassador-container
- name: nginx
mountPath: /etc/nginx/conf.d
- containerPort: 80
- name: nginx
name: nginx-config
- key: reverse-proxy-drop-useragent
path: default.conf


➜  ~ kubectl apply -f 00-init.yaml
service/adil-service created
configmap/nginx-config created

➜ ~ kubectl apply -f 01-ambassador.yaml
pod/adil-pod created


The request with an empty User-Agent header is dropped by the ambassador container.

Sidecar Container Pattern

The secondary container enhances the functionality of the primary container. e.g., HTTP Response cache, sync files between the primary container and an external resource, notifying the primary container if a configuration changes or something changes in an external source