How many side-car proxy is too much in a pod

user_9659987 0
Viewed 166

I am currently studying distributed systems and have seen that many businesses relies on side-car proxy pattern for their services. For example, I know a company that uses an nginx proxy for authentication of their services and roles and permissions instead of including this business logic within their services.

Another one makes use of a cloud-sql-proxy on GKE to use the Cloud SQL offering that comes on google cloud. So on top of deploying their services in a container which runs in a pod, they is a proxy just for communicating with the database.

There is also istio which is a service mesh solution which can be deployed as a side-car proxy in a pod.

I am pretty sure there are other commonly know use-cases where this pattern is used but at some point how much is too much side-car proxy? How heavy is it on the pod running it and what are the complexity that comes with using 2, 3, or even 4 side car proxys on top of your service container?

kubernetes distributed-system cloud containers proxy
1 Answers

I recommend you to define what really you need and continue your research based on this, since this topic is too broad and doesn't have one correct answer.

Due to this, I decided to post a community wiki answer. Feel free to expand it.

There can be various reasons for running some containers in one pod. According to Kubernetes documentation:

A Pod can encapsulate an application composed of multiple co-located containers that are tightly coupled and need to share resources. These co-located containers form a single cohesive unit of service—for example, one container serving data stored in a shared volume to the public, while a separate sidecar container refreshes or updates those files. The Pod wraps these containers, storage resources, and an ephemeral network identity together as a single unit.

In its simplest form, a sidecar container can be used to add functionality to a primary application that might otherwise be difficult to improve.

Advantages of using sidecar containers

  • sidecar container is independent from its primary application in terms of runtime environment and programming language;
  • no significant latency during communication between primary application and sidecar container;
  • the sidecar pattern entails designing modular containers. The modular container can be plugged in more than one place with minimal modifications, since you don't need to write configuration code inside each application.

Notes regarding usage of sidecar containers

  • consider making a small sidecar container that doesn't consume much resources. The strong point of a sidecar containers lies in their ability to be small and pluggable. If sidecar container logic is getting more complex and/or becoming more tightly coupled with the main application container, it may better be integrated with the main application’s code instead.

  • to ensure that any number of sidecar containers can works successfully with main application its necessary to sum up all the resources/request limits while defining resource limits for the pod, because all the containers will run in parallel. Whole functionality works only if both types of containers are running successfully and most of the time these sidecar containers are simple and small that consume fewer resources than the main container.

user_165592920
Related