Multi-container Pods

Why Multiple Containers in One Pod?

Most pods run a single main container. But sometimes two or more containers need to share storage, localhost networking, or lifecycle closely enough that putting them in one pod makes sense.

Common Patterns

Sidecar Pattern

A sidecar supports the main app, such as shipping logs, proxying traffic, or refreshing configuration.

Ambassador Pattern

An ambassador acts like a local proxy for external services. The main app talks to localhost, and the ambassador forwards requests outward.

Adapter Pattern

An adapter transforms output from the main app into a format expected by another system.

Init Containers

Init containers run before main containers start. They are perfect for setup steps such as waiting for dependencies or preparing files.

Shared Volumes

Containers in a pod can mount the same volume. That is a common way for an init container or sidecar to hand off data to the main app.

Full Example: App + Sidecar + Init Container

apiVersion: v1
kind: Pod
metadata:
  name: app-with-sidecar
  labels:
    app: demo
spec:
  volumes:
    - name: shared-data
      emptyDir: {}
  initContainers:
    - name: init-content
      image: busybox:1.36
      command: ['sh', '-c', 'echo Ready > /work/status.txt']
      volumeMounts:
        - name: shared-data
          mountPath: /work
  containers:
    - name: app
      image: nginx:1.27
      volumeMounts:
        - name: shared-data
          mountPath: /usr/share/nginx/html
    - name: sidecar
      image: busybox:1.36
      command: ['sh', '-c', 'while true; do date >> /work/sidecar.log; sleep 30; done']
      volumeMounts:
        - name: shared-data
          mountPath: /work

Why This Example Works

• The init container writes a file before the app starts.
• The app serves data from the shared volume.
• The sidecar keeps writing log-like information into the same volume.

When Not to Use Multi-container Pods

Do not put unrelated services into one pod just to save YAML. If the containers scale differently or should be managed independently, they probably belong in separate pods.

A pod should represent one tightly coupled unit, not an entire application stack crammed together.