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:
The idea for a sidecar container is to add some functionality not present in the main container. Rather than bloating code, which may not be necessary in other deployments, adding a container to handle a function such as logging solves the issue, while remaining decoupled and scalable. Prometheus monitoring and Fluentd logging leverage sidecar containers to collect data.
The basic purpose of an adapter container is to modify data, either on ingress or egress, to match some other need. Perhaps, an existing enterprise-wide monitoring tools has particular data format needs. An adapter would be an efficient way to standardize the output of the main container to be ingested by the monitoring tool, without having to modify the monitor or the containerized application. An adapter container transforms multiple applications to singular view.
Ambassador containers allows for access to the outside world without having to implement a service or another entry in an ingress controller: proxy local connection, reverse proxy, limits HTTP requests, re-route from the main container to the outside world.