Ambassador and Adapter Patterns

The sidecar pattern is broad. Two specific variations have names because they solve recurring problems with distinct structures. Understanding the ambassador and adapter patterns by name is expected on the CKA exam and in design discussions.

The ambassador pattern: abstracting outbound access

An ambassador container sits between the main container and an external service. The main container always connects to localhost:<port>. The ambassador handles the actual connection to the external service, which might be in a different environment, require credentials, or use connection pooling.

The key insight: the application does not need to know where the real service is or how to connect to it. The ambassador handles that. The application code does not change between environments. Only the ambassador’s configuration changes.

A concrete scenario: a development database is at localhost:5432. In production, the database is a managed service with TLS and credentials. Without the ambassador pattern, the application code must handle two connection paths. With it, the application always connects to localhost:5432. The ambassador sidecar handles the real connection.

nano ambassador-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: ambassador-pod
spec:
  containers:
    - name: app
      image: busybox:1.36
      command:
        - sh
        - -c
        - |
          while true; do
            echo "connecting to localhost:8888"
            sleep 5
          done
    - name: ambassador
      image: busybox:1.36
      command:
        - sh
        - -c
        - |
          echo "ambassador: proxying connections to external-service:8888"
          sleep 3600

kubectl apply -f ambassador-pod.yaml
kubectl logs ambassador-pod -c app
kubectl logs ambassador-pod -c ambassador

The two containers run independently. In production, the ambassador would be a real proxy like Envoy configured with the external service’s credentials, while the application code only ever sees localhost.

The adapter pattern: normalizing output

An adapter container transforms the output of the main container into a format that an external system expects. The main container produces data in its natural format. The adapter converts or enriches it before forwarding.

The most common real-world example: a legacy application emits metrics in a proprietary format. Prometheus expects a specific text-based exposition format. An adapter sidecar reads the legacy metrics and exposes them in the Prometheus format.

The application container does not change. The adapter handles the translation. When Prometheus changes its format, only the adapter is updated.

nano adapter-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: adapter-pod
spec:
  containers:
    - name: legacy-app
      image: busybox:1.36
      command:
        - sh
        - -c
        - |
          while true; do
            echo "stats: requests=42 errors=1 latency_ms=120"
            sleep 5
          done
    - name: metrics-adapter
      image: busybox:1.36
      command:
        - sh
        - -c
        - |
          while true; do
            echo "# HELP http_requests_total Total requests"
            echo "http_requests_total 42"
            echo "http_errors_total 1"
            sleep 5
          done

kubectl apply -f adapter-pod.yaml
kubectl logs adapter-pod -c legacy-app
kubectl logs adapter-pod -c metrics-adapter

The legacy app produces one format. The adapter produces a normalized format that monitoring systems understand.

Comparing the three patterns

All three use the same mechanics: shared volumes or localhost communication within a Pod. The names describe the intent, not a different technical mechanism.

kubectl delete pod ambassador-pod adapter-pod

The ambassador abstracts where you connect; the adapter normalizes what you produce. Both are specializations of the general sidecar concept. The next lesson covers init containers, which run before the main containers start and are designed for one-time setup tasks.