Kubernetes Patterns – Sidecar

Motivation

On the last week, I’ve blogged about Ambassador Pattern.

This pattern is very important when we are trying to solve network issues in the Microservices architecture, in a few words Ambassador is a kind of proxy, to help in the service-to-service communications.

Today we’ll talk about Sidecar Pattern, it’s an interesting pattern when we are looking for help with network issues, but as we will see during this post, there are more features which this pattern enable for us.

 

Context

In the containers world, we need to follow the container Golden Rule, the container should have one single purpose to exist. That is the most important thing to follow.

When we are developing applications using the microservice as an Architectural guide, we shouldn’t worry about concerns related to infrastructures, like log collector, network handlings and other orthogonal concerns. These concerns are more related to the platform where we are running our service than our application code.

We should use our platform to help us with these activities. Kubernetes is a “de-facto” platform to run containers workloads. We can use Kubernetes to deploy a dedicated infrastructure to handle internal network traffic, ISTIO for an example. In this case, ISTIO is our “platform” to help with network handlings.

I’ve blogged about my first impressions about ISTIO and Service Mesh

Kubernetes has the primitive called PODs, the small unit of computational resources in the kubernetes ecosystem, the POD is able to have multiple containers, in that scenario the Sidecar Pattern is a perfect solution to help the main container.

Let’s look at the POD anatomy (the yellow one)

Solution

The Sidecar container should add some additional functionalities to the microservice container. The important part to pay attention here is the sidecar should run in a different process and is not able to change anything in the microservice container.

In the same POD, containers are able to share the volumes and the same network, it means the containers can reach each other via “localhost” for an example.

Let’s analyze an example.

In the real microservices architecture, we might have different services and many instances of these services, but, how we are able to look effectively at the logs?

We need a centralized tool that collects these logs, also we need an effective way to query these data to find something that helps us to troubleshoot and debug distributed systems.

Is that role of the main container to send these logs for service in the cloud? Maybe a Sidecar container is able to collect these logs, they are sharing the volumes, and send these data to the cloud.

The sidecar “enrich” the main container functionalities sending data to the cloud systems. That is the main role of Sidecar Container.

Look at the image below:

As we can see, the logger container sends the data to the cloud storage, the logger read data from POD volumes, because they are sharing the disk.

The microservice container doesn’t care about the logs, the main container should play to service our business only.

That is one example where sidecar container can help us adding extra functionalities for our main container.

In the Service Mesh Infrastructure, the sidecar container can help us adding some extra functionalities to help us to handle network issues, it is another example.

Conclusion

The Sidecar Pattern is very useful when we are working in distributed systems, especially in containers world.

It will increase our productivity because we don’t need to pay attention to infrastructure stuff and it makes our code more concise than ever without infrastructure handlings.

Then, it is time to say goodbye to Netflix Ribbon, Netflix Eureka and Netflix Hystrix and put their responsibilities to sidecar container.

References

Kubernetes Pattern Book

Microsoft Azure Docs