Multi-Container Patterns

Why Multiple Containers?

Containers in the same Pod share:

• Network namespace — same IP, communicate via localhost
• Volumes — can mount the same emptyDir or PVC
• Lifecycle — start and stop together

Use multiple containers to add cross-cutting concerns without modifying the main app image.

The Four Patterns

1. Sidecar

Augments the main container. Runs alongside it throughout the Pod lifetime.

Pod
├── App Container      → writes logs to /var/log/app/
└── Sidecar Container  → reads /var/log/app/, ships to Elasticsearch
        (shared emptyDir volume)

Examples: log shipping, metrics collection, TLS proxy, config reloader.

2. Init Container

Runs to completion before the main container starts. Use for prerequisites.

Init Container 1: wait for DB to be ready   → exit 0
Init Container 2: run migrations            → exit 0
Main Container:   start application         → (runs forever)

3. Ambassador

Proxies outbound connections. Main container talks to localhost; ambassador forwards to the real backend.

Pod
├── App Container    → connects to localhost:6379
└── Ambassador       → forwards :6379 to Redis Cluster

Benefit: swap the backend without changing the app.

4. Adapter

Normalizes output format from the main container for external consumers (e.g. monitoring).

Pod
├── App Container   → exposes metrics at /metrics in proprietary format
└── Adapter         → reads /metrics, converts to Prometheus format, exposes :9090

Key Constraint

Containers cannot listen on the same port within a Pod (shared network namespace). Assign different ports to each container.