Multi Container PODs
In this tutorial, we will discuss about multi container PODs in Kubernetes.
The multi container pods are the pods that contain two or more related containers that share resources like network space, shared volumes, etc and work together as a single unit.
If you need to run a single container in Kubernetes, then you have to create a pod for it which is nothing but Single Container Pod.
If you have to run two or more containers in a pod, then the pod created to place these containers is called a Multi Container Pod.
Basically, these are helper processes or containers enhance the main containers by providing additional functionality.
Multi container PODs share the same life cycle, which means they are created together and destroyed together. They share the same network space which means they can refer to each other as localhost and they have access to the same storage volumes.
This way you don’t have to establish volume sharing or services between PODs to enable communication between them.
Since containers should not be deployed directly to save ourselves from inevitable disasters, we use pods to deploy them as discussed previous tutorials.
But what if there are tightly-coupled containers, for example, a database container and a data container, should we place them in two different pods or a single one? This is where a Multi Container Pods comes in.
To create a multi container POD, add the new container information to the POD definition file.
apiVersion: v1
kind: Pod
metadata:
name: my-webapp
spec:
containers:
- name: my-webapp-container
image: my-webapp
ports:
- containerPort: 8080
- name: queue-listener
image: queue-listener
Design-patterns Of Multi Container Pods
There are 3 common patterns when it comes to designing multi container PODs.
- Sidecar pattern
- Adaptor pattern
- Ambassador pattern.
1. Sidecar pattern
Sidecars derive their name from motorcycle sidecars. While your motorcycle can work fine without the sidecar, having one enhances or extends the functionality of your bike, by giving it an extra seat.
Similarly, in Kubernetes, a sidecar pattern is used to enhance or extend the existing functionality of the container.
Your container works perfectly well without the sidecar, but with it, it can perform some extra functions. Some great examples are using a sidecar for monitoring and logging and adding an agent for these purposes.
The most common sidecar containers are logging utilities, sync services, watchers, and monitoring agents.
2. Adapter Pattern
The Adapter is another pattern that you can implement with multiple containers.
The adapter pattern is used to standardize the output by the primary container. Standardizing refers to format the output in a specific manner that fits the standards across your applications.
For instance, an adapter container could expose a standardized monitoring interface to the application even though the application does not implement it in a standard way. The adapter container takes care of transforming the output into what is acceptable at the cluster level.
3. Ambassador Pattern
The ambassador design pattern is used to connect containers with the outside world.
In this design pattern, the helper container can send network requests on behalf of the main application. It is nothing but a proxy that allows other containers to connect to a port on the localhost.
This is a pretty useful pattern especially when you are migrating your legacy application into the cloud.
For instance, some legacy applications that are very difficult to modify, and can be migrated by using ambassador patterns to handle the request on behalf of the main application.