Multi-Container Pods

May 20, 2026

Rule

Never put multiple microservices in one Pod: helpers/init only
Same Pod: shared localhost network + shared volumes

Init containers

Under spec.initContainers: run before app containers
Run sequentially; each must succeed before next
Failure → Pod restart, all inits re-run
Terminate when done; no probes
Status: Init:0/1 → Init:CrashLoopBackOff → Running
v1.35 native sidecar shape: init container with restartPolicy: Always

initContainers:
- name: configurer
  image: busybox
  command: ['sh', '-c', 'echo config > /usr/shared/app/config.json']
  volumeMounts: [{name: configdir, mountPath: /usr/shared/app}]
containers:
- name: web
  volumeMounts: [{name: configdir, mountPath: /usr/shared/app}]
volumes:
- name: configdir
  emptyDir: {}

Patterns comparison

Pattern	Purpose	Lifetime
Init	Setup before app	Terminates
Sidecar	Helper (logs, sync, watch)	Full Pod life
Adapter	Transform output for external systems	Full Pod life
Ambassador	Proxy outbound calls (rate limit, auth)	Full Pod life

Sidecar: e.g. monitor nginx error log via shared emptyDir
Adapter: transform app output (strip timestamps) without changing app code
Ambassador: app calls localhost:8081 → proxy handles external API

kubectl (multi-container)

kubectl logs <pod> -c <container>
kubectl logs <pod> -c <init-container>
kubectl exec <pod> -it -c <container> -- /bin/sh
kubectl get po <n>   # READY 2/2

Failures

Symptom	Cause
Stuck `Init:*`	Init container failing: `logs -c <init>`

Exam tips

Without -c, kubectl targets first container in spec
Init failure restarts entire init chain: make logic idempotent
Shared files need both volumes[] and matching volumeMounts[] in each container