Kubernetes Multi Container Pods

There are some use cases where you may want to run multiple containers inside the same Pod. For example, you could have a microservice running in one container that writes logs to a volume. A second container running a log agent could capture and push those logs to a centralised logging solution. In this instance both containers run inside the same Pod and work as a unit.

Containers Communicating within a Pod

• Shared Network – containers running in the same Pod share the same network space and can access one another via localhost. In the diagram below Container 1 can access Container 2 on localhost:8090 and Container 2 can access Container 1 on localhost:8080. Containers can access one another whether the ports are exposed to the cluster or not.

• Shared Storage Volume – containers running in the same Pod can share a storage volume. A common use case is where one container write files to a volume while another container reads those files from the same volume. For this to work the volume must be mounted in both containers.

• Shared Process Namespace – This allows containers in the same Pod to interact by signalling one another’s processes. To enable Shared Process Namespace you need to set shareProcessNamespace: true in the Pod spec.

Multi Container Design Patterns

• Sidecar Pattern – The sidecar pattern uses a second container in a Pod to provide supplementary functionality for the primary container. For example, if you had a container running a web server like nginx, you could have a side car container that periodically pulls new content from a remote data source and makes that content available to the web server container.
• Ambassador Pattern – The ambassador pattern uses a second container in a Pod to proxy incoming network traffic and then route that traffic to the primary Pod. For example, if traffic into your Pod is via TLS you may use an ambassador container to act as the TLS termination point and then pass the unencrypted traffic onto the primary container via plain HTTP.
• Adapter Pattern – The adapter pattern uses a second container to perform some kind of  transformation of data coming from the primary container. An example is a container that takes logs data produced by the primary Pod and performs some kind of transform before making those logs available outside the Pod.

Shared Storage Volume Multi Container Sample

The following is a very simple multi container Pod definition. Its far from a real life example but it does show how 2 containers can run inside the same Pod and share a Volume. The log-writer container writes a message to /var/demo/logs/hello.txt on startup.  var/demo/logs is a mounted Volume which is also accessible to the second container, log-reader. When log-reader starts its sleeps for 10 seconds before logging the contents of /var/demo/logs/hello.txt. This demonstrates in very simple terms, how multiple containers inside a Pod can share a volume.

apiVersion: v1
kind: Pod
metadata:
  name: log-writer-reader
spec:
  containers:
    - name: log-writer
      image: busybox
      imagePullPolicy: Always
      command: ['sh', '-c', 'echo hello from log-writer container >> /var/demo/logs/hello.txt & sleep 3600']
      volumeMounts:
        - name: log-volume
          mountPath: /var/demo/logs
    - name: log-reader
      image: busybox
      imagePullPolicy: Always
      command: ['sh', '-c', 'sleep 10 && cat /var/demo/logs/hello.txt']
      volumeMounts:
        - name: log-volume
          mountPath: /var/demo/logs
  volumes:
    - name: log-volume

After creating the Pod you will see 2 of 2 containers marked as running.

Looking at the log-reader container log you can see the contents of /var/demo/logs/hello.txt.

The sample code for these notes is available here.