Why Multiple Containers in a Pod

A Pod is not strictly one container. You can run multiple containers inside the same Pod. They share a network namespace (the same IP address and port space) and can share volumes. This co-location enables patterns that would be awkward or impossible if the containers ran in separate Pods.

But the ability to run multiple containers in a Pod does not mean you should always do it. The principle to follow is: containers in the same Pod must work together to serve a single concern. If they could be decoupled and run separately without losing functionality, they should be.

What containers in a Pod share

nano shared-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: shared-pod
spec:
  containers:
    - name: writer
      image: busybox:1.36
      command: ['sh', '-c', 'while true; do echo "$(date)" >> /shared/log.txt; sleep 2; done']
      volumeMounts:
        - name: shared-vol
          mountPath: /shared
    - name: reader
      image: busybox:1.36
      command: ['sh', '-c', 'while true; do tail -1 /shared/log.txt; sleep 3; done']
      volumeMounts:
        - name: shared-vol
          mountPath: /shared
  volumes:
    - name: shared-vol
      emptyDir: {}

kubectl apply -f shared-pod.yaml

Two containers, one volume. writer appends timestamps to a file every 2 seconds. reader reads the last line of the same file every 3 seconds.

kubectl logs shared-pod -c reader

The -c flag selects which container’s logs to read. Without it, kubectl logs fails on a multi-container Pod and tells you to specify a container name.

The two containers communicate through a shared file on the emptyDir volume. They could equally communicate over localhost: if writer starts an HTTP server on port 8080, reader can reach it at localhost:8080. No service or network policy needed.

Observing multi-container Pods

kubectl describe pod shared-pod

The Containers section lists both writer and reader with their individual status, restart counts, image, and command. Each container has independent lifecycle status even though they share the Pod.

kubectl get pods

The READY column shows 2/2 when both containers are running. If one container crashes, you see 1/2 even though the Pod itself is still present. The Pod is not restarted: only the failed container is restarted by the kubelet.

kubectl logs shared-pod -c writer
kubectl logs shared-pod -c reader

Each container has separate log streams.

When not to use multiple containers

Two containers belong in the same Pod only when they are tightly coupled and must run on the same node sharing the same lifecycle. Examples that do not qualify:

• A frontend and a backend that communicate over HTTP: they should be separate Pods with a Service between them
• A database and an application: separate Pods, separate lifecycle, separate scaling
• Two independent microservices that happen to be part of the same application: separate Pods

kubectl delete pod shared-pod

The shared network namespace and shared volumes are the two mechanisms that make multi-container Pods useful. The next lesson covers the sidecar pattern, the most common application of these shared resources.