In this post, we will see how does Kubernetes application uses a side-car container to its advantage to implementing new features. More information about what is sidecar container and how it can be used can be found here
For getting into the depth of this topic we will go into the depth of the container world and will figure out what is sharable in between these containers and how do you take advantage of the sidecar in your future project. In future blogs, we will see how Kubernetes implements these sidecars.
Linux Namespaces.
Wait why are we discussing Linux namespaces over here. Aren’t we discussing sidecar containers? Well, sidecar containers use the power of Linux namespaces. The main selling point of containers is ISOLATION, right? Here comes Linux Namespaces. Linux Namespaces make sure that two process does not know about each other even running in the same machine.
Let’s take the example of https://play.golang.org. It’s a site where the user some go code and share it with others. I know it’s a handy website but you can write some malicious code that can try to read all the processes running in the system and send back the response to you. This is will pose a security threat to the system and we should mitigate risk. So as you can guess Linux Namespace will come to the rescue. So there are different types of kernel namespaces that will work together to provide the ultimate isolation which you need. These are:-
Process Namespace: As the name suggests this will provide isolation for the process. So process running in a single namespace will not be able to see the outside world.
Network Namespace: Provides network isolation.
Mount Namespace: Each process can see its own root directory. This means that the process in the different namespaces will not see each other files.
User Namespace: The process can have root privilege in its namespace.
UTS(Unix TimeSharing System) Namespace: Segregation of hostnames.
IPC Namespace: Separating IPC resources.
Above is the image which tells us how to process is bounded by boundaries(namespaces). Now it’s time to address the elephant in the room, right? If the process lives in its own boundary then how do resources being shared among sidecar containers. The answer to this is simple Sidecar containers share namespaces. It does not share all namespaces but some namespaces which will help us to do some wonderful things. The question of how does it do it will be questioned which we will discuss in a different blog.
Now you can see the namespace being shared between the containers. Not all namespaces are being shared. Through Namespace sharing, we can implement a number of features like:-
Metrics Exporters
Some application does not emit metrics and you need third party tools to do it. Example Redis exporters. Redis does not emit metrics by default. It hits the Redis running at localhost and then gathers information and exposes it.
Service Mesh
It uses an envoy proxy as a sidecar container. It uses the advantage of a shareable network namespace. It hijacks the traffic coming or going out to the container and let’s do some cool things.
Vault’s Realtime Secret Update
Hashicorp Vault uses sidecar containers to provide real-time secrets to main applications
These are some profound use cases of sidecar containers. In the upcoming blog, we will see what does Kubernetes does under the hood to implement a sidecar container mechanism.
If you are preparing for DevOps and SRE interviews, you check out this channel.
https://www.youtube.com/c/LetUsDevOps
