Saturday, September 1, 2018

Container Patterns - SIde Car, Ambassador and Adapter

Containers are often used to run a single micro service application but when we go to the real world we need multiple containers to solve problems.

Why Pod and why Not Containers?
Many times we may think of why pod and why not containers. A Pod is a smallest unit of workload that can be deployed. A Pod can have one container running which will do a specific job but there would be cases where we require pod to have multiple containers.

The taught of pod is very important. A Container should run 1 process as a standard ( though it can run multiple process ) and what if need to manage the container. What if we need to have some additional information like restart policy of the container, what to do if the container stops, how to check if the container is up and running the liveness probe or perform certain action based on certain things.

For this we have to run the application process and also another process to manage the container. This will cause extra load on the container and application running inside the container. Hence people came up with a  Pod taught where multiple containers that are tightly coupled will be running inside a pod and the pod will be managed as a single entity.

One another advantage of using pod is usage of namespaces. Name spaces are one of the major component for the containers and multiple containers running in a pod can always share certain things including network, IPC etc. They can also share the volumes. Because of these properties container can efficiently communicate between themselves in a pod ensuring data locality. This is one of the reason why pod was given the way to run more than one containers.

Multi-Container Pods - Most of the reasons why we use a multi container pod is to support primary application. In this article we will see patterns that support in running multi container pods,

Side Car Pattern -  One of the most used container pattern is the sidecar. In this a pod will have multiple containers running one is the main application and the other one which helps the main application which we call as the sidecar. The job of the side car container is to assist the main application container. The main container is unaware of the side car container.

A best example for the sidecar is the logging container. Let's say i have a Pod with 2 containers running. One is the main application container which will log the output to the stdout. The job of the sidecar container is to collect the stdout logs and pass them to the central logging system. 

Lets see an example for the side car container pattern. In this example we will have a nginx main application container which will read the data from a index.html file that is available in the attached volume and display in the page. The side car will be feeding data to the index.html to the same attached volume by adding a date value for every 1 second. The main application unaware of the changes done to the index.html will display the context on the main page 

[root@manja17-I13330 kubenetes-config]# cat side-car-pattern-pod.yml
apiVersion: v1
kind: Pod
  name: side-car
  - name: html
    emptyDir: {}
  - name: web
    image: nginx
    - name: html
      mountPath: /usr/share/nginx/html
  - name: backend
    image: debian
    - name: html
      mountPath: /html
    command: ["/bin/sh", "-c"]
      - while true; do
          date >> /html/index.html;
          sleep 1;

[root@manja17-I13330 kubenetes-config]# kubectl exec side-car -c web -- /bin/cat /usr/share/nginx/html/index.html

[root@manja17-I13330 kubenetes-config]# kubectl exec side-car -c backend -- /bin/cat /html/index.html

The Side Car pattern may look some thing like this,
Another example could be to use have web server deployed with the sidecar container which sole job is to synchronize file system with a git repository.

Ambassador Pattern - The pattern advocates usage of additional containers as proxies to the external group of servers. We can have a pod with 2 containers , 1 being the main application and second one getting the details from the group of external containers. 

Let's say we have 3 external redis all in sync with each other. We have  multi container pod with one pod being the user interface and other pod acting as a ambassador to connect to the  external redis. This pod will be the one responsible for connecting to any of the redis external service. The pattern may look something like this,
From the above pattern, the nginx ( main application ) will connect to the ambassador container via localhost. The ambassador container in turn will connect to the external cluster of redis services. The main application don't know which service processed the request.

Adapter Pattern -  This container pattern talks about standardising output/format. Let's say we have multiple main container running and they all generate log content. Now we have a monitoring tool which will read specific format files and save them for future use. Our main containers may generate logs but not in the format that are understandable by the monitoring tool. In this case we will have a adapter pattern container which will take all the outputs from all containers logs , changes them to a format understandable by the monitoring tool. The adapter container once changing the format will send them to the monitoring tool. 

Other Patterns - There are some other patterns including Leader election, Work Queues  and scatter-gather patterns. All these patterns are supported indirectly by kubernetes.

We will see one more article on how these are implemented.

No comments :

Post a Comment