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?
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.
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: