Routing without an ambient mesh

To understand how routing in ambient mode works, let's first take a step back and review how in-cluster routing looks like without a service mesh and in a service mesh that uses a sidecar architecture.

Routing without a service mesh

In the following example, the client app sends a request to the product page. In order for the product page to also show user reviews, the reviews app is called. All traffic between pods is unencrypted and sent in plain text.

Routing in an Istio service mesh with sidecars

Now, let's look at how routing works in an Istio service mesh that uses a sidecar architecture. For every pod that is part of the service mesh, an Envoy-based sidecar is injected into the pod that runs alongside the app. The sidecar intercepts all traffic that leaves or enters the pod. In order for the request from the client app to get to the product page, the traffic is first sent to the Envoy sidecar in the same pod, and then routed to the sidecar of the product page app before it is forwarded to the product page app. Traffic between sidecars is automatically secured via mutual TLS (mTLS).

Because Istio and Envoy operate on layer 7, all traffic between apps is always routed on layer 7, which can be expensive and require a lot of network hops. For some app-to-app communication however, layer 4 routing might be sufficient. Explore how ambient mesh solves this challenge with a sidecarless service mesh architecture.