Kubernetes - Proxy Outbound Traffic with an Ambassador Container

An ambassador container runs alongside the main application container in the same Pod, intercepting outbound traffic before it leaves. The app always connects to localhost:80 and stays unchanged. The ambassador controls where that request actually goes - swap the config, reload nginx, and the destination changes with no restart.

• Multi-Container Pods - Kubernetes Docs

Task 1 - Create the ConfigMap and Pod

Nginx listens on port 80 inside the Pod's shared network namespace, so wget localhost:80 from the app container hits the ambassador's nginx process directly. The ConfigMap holds the nginx config as a file, mounted into the ambassador container as a volume. httpbin is a pre-deployed in-cluster service running in the infra namespace that returns simple JSON responses - /uuid returns a random UUID, /ip returns the caller's IP.

Steps:

• Create a ConfigMap named nginx-proxy-config with a key default.conf containing:

server {
  listen 80;
  location / {
    proxy_pass http://httpbin.infra/uuid;
  }
}

• Create a Pod named ambassador-pod with two containers:
  • Container app, image busybox, command ["sh", "-c", "while true; do wget -qO- localhost:80 && echo && sleep 3; done"]
  • Container ambassador, image nginx:alpine, mounts the nginx-proxy-config ConfigMap at /etc/nginx/conf.d

Task 2 - Switch the Ambassador to /ip

ConfigMap volumes sync to their mounted path automatically when the ConfigMap changes, but nginx needs an explicit reload to pick up the new file. The reload happens inside the running container with no Pod restart.

Steps:

• Edit nginx-proxy-config and change proxy_pass from http://httpbin.infra/uuid to http://httpbin.infra/ip
• Wait up to 60 seconds for the volume to sync, then reload nginx inside the ambassador container - run it twice if the logs do not switch on the first reload

The adapter pattern applies a similar idea to inbound data normalization: Kubernetes - Normalize Application Output with an Adapter Container.