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
Podshare 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
Podcan 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
Podto interact by signalling one another’s processes. To enable Shared Process Namespace you need to set
shareProcessNamespace: truein the
Multi Container Design Patterns
- Sidecar Pattern – The sidecar pattern uses a second container in a
Podto 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
Podto 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
Podand performs some kind of transform before making those logs available outside the
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
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 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
The sample code for these notes is available here.
Leave A Comment