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

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
metadata:
  name: pod-name
spec:
  containers:
  - 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

00-init.yaml

---
apiVersion: v1
kind: Service
metadata:
  name: adil-service
spec:
  selector:
    app: adil-pod
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-config
data:
  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.

01-ambassador.yaml

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

Apply:

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

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

Test:

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