A guide to Kubernetes Multi-container Pods

First, let's talk about what is a Kubernetes Pod. So, a Pod is the atomic unit of Kubernetes. A Pod is like an environment that wraps up one or more containers inside itself. Kubernetes isolates a particular small area in the host server Operating System, and then creates some kernel namespaces and provides a separate private network to that particular area to provide an isolated environment for the containers of the Pod.

Now, a pod with more than just one container is called a multi-container pod.

All the containers of a single pod share common resources like node, volume, memory, filesystem, etc. They have the same lifecycle. They also have the same IP address, which means they can access each other with the localhost interface. This is only to make the connection faster between them.

We use multi-container pods, when there is a service you want to deploy, that has multiple(and very different) functionalities. So, we have to think in terms of 'group of containers' per service and not one container per service. So for example let's say we are using the Nginx container as a web-server, but to collect the logs from the web-server we have to use some other logging agent, and it is a good practice to configure both the containers in a single pod.

Now, there are some general patterns for multi-container pods that we should know about:-

1. Sidecar Pattern: In sidecar patterns multi-container pods, along with the main container, there is another container(called Sidecar container) configured that extends the functionality of the main container. Although, the main container can also work without the Sidecar container. An example of a Sidecar pattern is the same that has been just discussed, i.e., the Nginx-logging agent one. Architecture

1. Ambassador Pattern: Ambassador pattern is a useful way to allow containers to connect to the outside world. The Ambassador container basically allows the main container to connect to a port on localhost, where the ambassador container can proxy(forward) the connection to the required destination. Because all the containers of a pod share the same IP address, your main container can open a connection on the localhost which can be further forwarded to the desired destination. For example, let's say you want to send some data to three different databases, where different chunks of data are to be sent to a different database. And, to handle this problem of "which chunk is to be sent to which database", you want to configure another container(called Ambassador container), for the sake of "Separation of Concerns". The main container will send all the data to the Ambassador container, and then the Ambassador container will proxy the data to the corresponding database.

1. Adapter Pattern: The Adapter pattern is used where there is a need to normalize the format of the output of various containers. For example, say you have an application in which all the containers are generating logs in different formats, and we want to convert them into a single format before sending them to a central logging server. So, to do that, we configure one more container(called the Adapter container). Now, because these containers share the same filesystem, it will be very easy to cooperate with each other.

Note: The syntax for pod definition files for all three patterns is the same, which is :

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx-container
    image: nginx:latest
  - name: debian-container
    image: debian:latest

That is it about Multi-container Pods. Thank you for your time.