⌂ Home

Multi-Container Pod Patterns

Interactive guide to sidecar, ambassador, adapter patterns and container lifecycle hooks within a Pod.

Multi-container Pods work because containers inside the same Pod share a network namespace and can also share storage. The Pod boundary defines their close coupling.

Core Model

Understand the Concept First

Sidecar pattern

A helper container runs continuously alongside the app and supports it.

Ambassador pattern

A proxy container manages communication to external or remote services.

Adapter pattern

A helper container transforms app output into a standardized format.

Lifecycle Flow

Multi-Container Pod Collaboration Flow

1

Pod starts

Multiple tightly related containers start inside one Pod.

2

Hooks may run

postStart and preStop hooks can coordinate setup and graceful shutdown.

3

Containers share localhost

They communicate through the same Pod network namespace.

4

Support behavior runs continuously

Helper containers provide proxying, adaptation, or sidecar support to the main app.

A multi-container Pod makes sense only when the containers are truly operationally coupled and benefit from sharing the same Pod boundary.
Visual Diagrams

Multi-Container Pod Patterns

Sidecar Pattern: Log Shipping

Pod (Shared Network + Storage) Main Container nginx web server Writes access logs to /var/log/nginx/ Shared Volume: logs-volume Main application container 📁 Shared emptyDir Volume Shares logs volume Sidecar Container fluentd log shipper Reads logs from /var/log/nginx/ Shared Volume: logs-volume Sidecar collects and ships logs 📁 Shared emptyDir Volume Ships to ☁️ Logs System Sidecar runs continuously alongside main app, sharing localhost network & storage

Ambassador Pattern: Database Proxy

Pod (Shared localhost network) Main Container Application Connects to: localhost:5432 (thinks DB is local) No complex routing configuration needed Application connects to localhost TCP localhost Ambassador DB Proxy Listens on: localhost:5432 Forwards to real DB with connection pooling, TLS, retry logic Ambassador proxies external services Proxies External DB postgres.example.com :5432 Real database External database service Ambassador mediates traffic to external services, adding features like retries and pooling

Adapter Pattern: Metrics Format Transformation

Pod (Shared Network + Storage) Main Container Legacy App Writes custom metrics to /metrics/app.log Format: req_count:42|time:1.2s errors:3|latency:450ms App writes custom format metrics 📁 Shared metrics volume Reads Adapter Container Metrics Transformer Reads custom format Transforms to Prometheus format requests_total 42 errors_total 3 Adapter transforms metrics format 📁 Shared metrics volume Exposes Prometheus Scrapes :9090/metrics Standard format Monitoring system gets standard format Adapter transforms app output to match standard interfaces without modifying the app
All three patterns share the key principle: containers in the same Pod share network namespace (localhost) and can share volumes. Click the buttons above to explore each pattern.
YAML and Commands

Examples You Can Recognize Quickly

Pattern Summary
sidecar -> support service
ambassador -> local proxy
adapter -> format transformer
Lifecycle Hooks
postStart
preStop
Decision Guide

Pattern Comparison

Pattern Purpose Typical example
Sidecar Support app continuously Log shipper, metrics agent
Ambassador Proxy traffic for the app Database or service proxy
Adapter Transform app output Custom metrics to standard metrics format
The right pattern depends on whether the helper container is supporting behavior, proxying traffic, or translating output.
Use It Well

Practice and Real-World Thinking

Logging sidecars

Ship logs without modifying the main application binary.

Local traffic mediation

Proxy external services through an in-Pod ambassador container.

Observability adaptation

Standardize app output so existing tooling can consume it easily.