The idea of decoupling a large monolithic application into sub-components is known as microservices and it enables us to develop and deploy a set of independent, small, reusable code.

in simple terms, Microservices architecture can help us to scale up, and scale down the application as well as modify each service as required as opposed to modifying the entire application.

In real cases, we may need 2 services to work together and can be scaled up, or down together as per the need.

We need these 2 services to work together but like to be developed and deployed separately and here comes the multi-container pod concept.

Multicontainer pod shares the same lifecycle which means that are created together and destroyed together.

They share the same network space which means they can refer to each other as local host.

Also, they have access to the same storage volumes so we don't need to establish volume sharing or services between the pods to enable communication between them.

We can create multi-containers inside a pod by using the array behavior of containers inside the spec section, we just need to add container details.

Creation of multi-container pod using yaml:-

apiversion: v1
kind: Pod
metadata: 
     name: My_webapp
     labels: 
          name: My_webapp
spec: 
   containers:
       name: webapp
       image: image_webapp
       ports:
          containerPort: 8080
       name: log_agent
       image: image_log_agent

There are 3 common patterns when it comes to designing multi-container pod. the logging service example is known as a sidecar pattern and the other is the ambassador or adapter pattern for some applications.

Multi-Container Pod Design Patterns:-

[1]. SideCar Design Pattern

In a sidecar pattern, an application like a webapp container that saves its logs to a shared filesystem, and the logging service sidecar container sends the webapp's logs to a log aggregator like S3 bucket.

[2]. Adapter Design Pattern

An adapter pattern app container writes complex monitoring outputs which are going to be used by an adapter container which simplifies the output for an external monitoring system or service that requires standard data formats. In simple terms, an adapter container runs an agent that reads the main application’s data, processes it, then exports the normalized data to monitoring systems elsewhere in the network.

[3]. Ambassador Design Pattern

The ambassador pattern is a useful way to connect containers with the outside world. An ambassador container is essentially a proxy that allows other containers to connect to a port on localhost while the ambassador container can proxy these connections to different environments depending on the cluster's needs. This is a pretty useful pattern especially when we are migrating our legacy application into the cloud. For example, 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.

Thank you so much for taking your valuable time for reading.

I have tried my level best to explain as much information as possible in the easiest manner. Any feedback for further improvement will be highly appreciated!

We can connect at Rahul Kumar Verma | LinkedIn Rahul Kumar Verma (@RahulKu28171925) / Twitter