Explain the multi-container pod patterns: sidecar, init container, and ambassador.
Quick Answer
Init containers run to completion before app containers start (setup/migrations). Sidecars run alongside the app for the pod's life (logging, proxy, sync). Ambassador is a sidecar that proxies the app's outbound connections to simplify the app's view of the world.
Detailed Answer
Init containers execute sequentially and must each succeed before the main containers start — perfect for waiting on a dependency, running a schema migration, or fetching config; if one fails, the pod restarts it. Sidecars run concurrently with the app for the whole pod lifetime and extend it without changing its code — a log shipper reading a shared volume, a service-mesh proxy (Envoy) intercepting traffic, or a git-sync puller. Kubernetes 1.28+ even added native sidecar support (init containers with restartPolicy: Always) so sidecars start before and stop after the app cleanly. The ambassador pattern is a specialized sidecar: it proxies the app's outbound connections so the app just talks to localhost while the ambassador handles sharding, retries, or TLS to the real backend. All three exploit the pod's shared network and storage.
Code Example
spec:
initContainers:
- { name: migrate, image: myapp, command: ["./migrate"] } # runs first, to completion
containers:
- { name: app, image: myapp }
- { name: envoy, image: envoyproxy/envoy } # sidecar for the pod's lifeInterview Tip
Distinguish by lifecycle: init = runs to completion *before* app; sidecar = runs *alongside* for the pod's life. Mentioning native sidecars (1.28+ restartPolicy: Always) shows current knowledge.