Menu
I confused between Multi-Container Pod Design patterns.
(sidecar, adapter, ambassador)
What I understand is :
Sidecar : container + container(share same resource and do other functions)
Adapter : container + adapter(for checking other container's status. e.g. monitoring)
Ambassador : container + proxy(to networking outside)
But, According to Istio -Installing the Sidecar, They introduce proxy as a sidecar pattern.
Adapter is container, and Proxy is container too.
So, My question is What is differences between Sidecar pattern and Adapter&Ambassador pattern?
Is the Sidecar pattern concept contain Adapter&Ambassador pattern?
450
Sidecar pattern is about separating cross-cutting operations from a Microservice to reduce its internal complexity. For example, suppose there are several modules that we want to execute for each Microservice like logging, messaging, monitoring, etc.
An ambassador service can be thought of as an out-of-process proxy that is co-located with the client. This pattern can be useful for offloading common client connectivity tasks such as monitoring, logging, routing, security (such as TLS), and resiliency patterns in a language agnostic way.
The Adapter container is a simple express node server that reads from the location /var/log/file.log and produces JSON format. Let's implement a simple project to understand this pattern. The Adapter container is a simple express API that serves these logs as a JSON response. Here is the file server.js. server.js.
The Ambassador container is a special type of sidecar container which simplifies accessing services outside the Pod. When you are running applications on kubernetes it's a high chance that you should access the data from the external services.
First, you are right, the term sidecar container has now became a word for describing an extra container in your pod. Originally(?) it was a specific multi-container design pattern.
Sidecar pattern
An extra container in your pod to enhance or extend the functionality of the main container.
Ambassador pattern
A container that proxy the network connection to the main container.
Adapter pattern
A container that transform output of the main container.
This is taken from the original article from 2015: Patterns for Composite Containers
Your note on
But, According to Istio -Installing the Sidecar, They introduce proxy as a sidecar pattern.
In the patterns above, both Ambassador and Adapter must in fact proxy the network connection, but do it with different purpose. With Istio, this is done e.g. to terminate mTLS connection, collect metrics and more to enhance your main container. So it actually is a sidecar pattern but confusingly, as you correctly pointed out, all pattern proxy the connection - but for different purposes.
167
Sidecar is an additional container which extends the functionality of the main container. An example given everywhere is that you'd like to send logs to some external system. Without changing the business logic (the main container), you can deploy a logging-agent as a sidecar container.
Ambassador is a container that is a proxy to other parts of the system. A good example is that you deploy ambassador container which has credentials to Kubernetes API, so you don't have to use authentication from your client. Another good example is using Ambassador as proxy to the Redis caching cluster.
Now, the thing why it gets confusing is that both of these patterns are not limited to Kubernetes. However, the implementation of Ambassador in Kubernetes usually uses Sidecar. In other words, Ambassador is usually implemented as a sidecar container (as explained here).
Istio envoy is definitely implemented using as a sidecar container. I've never seen it described as Ambassador, probably because it does way more than just forwarding the requests to other parts ot the system.
This two articles explains Sidecar Ambassador, and Adapter patterns very well:
30
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
