Multi-Container Pod Design Patterns

All containers in one Pod share the same network namespace and can share volumes, which is what makes multi-container Pods useful for tightly coupled helper processes. Kubernetes recognizes two built-in patterns for containers listed under initContainers. A regular init container runs to completion, in the order listed, before the next init container or any main container starts — the fit for one-time setup such as cloning a config repo into a shared volume. A native sidecar container is also listed under initContainers, but sets restartPolicy: Always; the kubelet starts it, waits for it to report started (immediately, or once its startupProbe succeeds), then moves on to the next init container or the main containers — while the sidecar itself keeps running for the rest of the Pod's life, independently restartable if it crashes.

This sidecar mechanism has been stable and enabled by default since Kubernetes v1.33, reached after an alpha release in v1.28 and a beta period through v1.29–1.32. Before that history, "sidecar" was purely a naming convention — a second entry under the ordinary containers list, with no special startup ordering or shutdown ordering relative to the main container at all.

apiVersion: v1
kind: Pod
metadata:
  name: web-with-logs
spec:
  initContainers:
    - name: migrate-db
      image: migrator:2.1
    - name: log-shipper
      image: log-shipper:1.0
      restartPolicy: Always
  containers:
    - name: web
      image: web-app:3.0

Use a regular init container for anything that must happen exactly once before the app is reachable and then get out of the way — a database migration, a wait-for-dependency check, a config fetch. Use a native sidecar for anything that must keep running alongside the app for as long as it's up — a log shipper, a metrics exporter, a local proxy.

One nuance is worth knowing cold for the exam: a Job whose Pod includes a long-running native sidecar is not blocked from completing by that sidecar. Once every ordinary container in the Pod has exited, Kubernetes sends the sidecar a termination signal on its own, specifically so a Job with a sidecar can still be marked Complete rather than hang forever waiting for a helper process that was never meant to exit on its own.