CKAD — Ambassador Pattern

2 minute read

What Is the Ambassador Pattern?

The ambassador pattern uses a sidecar container as a proxy to simplify communication. The main container talks to localhost, and the ambassador handles routing to the actual service.

This decouples the application from service discovery — the app always connects to localhost:PORT, and the ambassador handles routing, load balancing, or connection pooling to the real backend.

How It Works

┌─────────────────────────────────────┐
│              Pod                    │
│                                     │
│ ┌───────────┐    ┌───────────────┐  │
│ │    App     │──→│  Ambassador   │──│──→ External Service
│ │ Container  │   │  (Proxy)      │  │
│ │            │   │               │  │
│ │ connects   │   │ routes to     │  │
│ │ localhost  │   │ real backend  │  │
│ └───────────┘    └───────────────┘  │
│       localhost:9000                │
└─────────────────────────────────────┘

All containers in a Pod share the same network namespace — they share the same IP address and can reach each other via localhost.

Common Use Cases

Use Case What the Ambassador Does
Database connection pooling Routes DB connections through a pool (e.g., PgBouncer)
API gateway proxying Forwards API requests to the correct upstream service
Service mesh proxy Manages traffic routing, retries, and circuit breaking (e.g., Envoy in Istio)
Rate limiting Limits outgoing requests to external services
TLS termination Handles encryption/decryption for the main container

Example: Ambassador Proxy

apiVersion: v1
kind: Pod
metadata:
  name: app-with-ambassador
spec:
  containers:
  - name: app
    image: busybox:1.36
    command: ["/bin/sh", "-c"]
    args:
    - |
      while true; do
        echo "Calling localhost:9000 (ambassador proxy)"
        wget -q -O- http://localhost:9000 || echo "proxy not ready"
        sleep 10
      done

  - name: ambassador
    image: nginx:1.27
    ports:
    - containerPort: 9000

kubectl apply -f app-with-ambassador.yaml

# Check logs from the app container
kubectl logs app-with-ambassador -c app

# Check ambassador container
kubectl logs app-with-ambassador -c ambassador

The app container sends requests to localhost:9000. The ambassador container (acting as a proxy) handles the routing. The app does not need to know the actual destination address.

Ambassador vs Direct Connection

Aspect Direct Connection Ambassador Pattern
App configuration Must know service URL, auth, retries Connects to localhost only
Service changes App must be updated and redeployed Only ambassador config changes
Connection pooling App handles its own connections Ambassador manages the pool
Reusability Logic duplicated across services Same ambassador image for many apps
Complexity Simpler for single services Worth it when proxying multiple services

When to Use the Ambassador Pattern

Good fit:

  • Your app connects to multiple external services and you want to abstract the routing
  • You need connection pooling without changing the application code
  • You want to add TLS, rate limiting, or retries without modifying the app

Not a good fit:

  • The app only talks to one simple service with a stable URL
  • Added complexity is not justified by the benefits

Exam tip: The CKAD exam may ask you to identify which multi-container pattern is being described. Remember: ambassador = proxy that routes traffic on behalf of the main container.

Next: Learn about output transformation with Adapter Pattern →

Updated:

You may also enjoy