 Hello, IstioCon. I'm Greg Hansen from SoloIO, and today I'm going to talk about the life of a request in Istio Ambient Mesh. Now, one of the things that I spent a lot of time on in Istio is debugging failed sidecar requests. Service A can't talk to Service B after I enabled Istio. My Istio-enabled pond can't reach Cloud Service X. Or why does my sidecar keep returning 503s? So tracing a request and figuring out which part of the path that's broken is something I spent a lot of time learning. And I think you should, too. Ambient isn't beta yet, but it's come to my attention that there are not nearly enough diagrams surrounding the new Ambient architecture in Istio. So let's see if there is an artist in me somewhere, and we're going to walk through some request scenarios in Ambient. Of course, I can't talk about Ambient without first rehashing the sidecar model. In the most basic case, every application pod in the mesh gets injected with a sidecar. The sidecar container consists of two processes, Envoy, which performs all the routing and traffic management functions that make up a Service Mesh, and Pilot Agent, which is the Istio process that feeds Envoy the various XDS configurations that it receives from the IstioD control plane. And not pictured, but worth mentioning is the init container that is also injected, which performs the IP tables traffic capture for the pod to route all inbound and outbound traffic to the Envoy process. In terms of requests, traffic is generally going from sidecar to sidecar or gateway to sidecar, just one Envoy process talking to another, unless you're making requests to external services. And how does that compare to Ambient? Well, there are no more sidecars. Nothing gets added to the user's application pods unless they themselves are adding it. There are now two new components, Z-Tunnel and Waypoint. Z-Tunnels are a brand new Istio component written in Rust that are designed to be fast, lightweight, and secure. Z-Tunnels are deployed per node and serve all pods co-located on the node. They enable the most basic mesh configurations for layer 4 features, such as mutual TLS, telemetry, authentication, and layer 4 authorizations. Waypoint Proxies provide layer 7 mesh features, such as virtual service routing, layer 7 telemetry, and layer 7 authorization policies. Waypoints are still based on Envoy and are deployed per namespace or service account. Let's take a look at a nice, simple request in Ambient. Pod A calls Pod B. The traffic is redirected to the node local Z-Tunnel. The Z-Tunnel instance sees the destination is on the same node, and the request is proxied to B. And what happens if the destination is on another node? Well, the client local Z-Tunnel sends the request to the destination's co-located Z-Tunnel, who then forwards to B. Boom, all done. Talk over, I can give everyone a few minutes back to their day. But wait, Dyn and I mentioned there are two new components. What about the Waypoints? Let's refer back to our original diagram. So it's a trick question. Those other diagrams were technically correct. Waypoints are entirely optional in Ambient. If you as a user just want mutual TLS between services in the mesh and don't care about layer 7 mesh features, such as virtual service routing, layer 7 telemetry, and layer 7 authorization policies, then that's all there is to it. I said Waypoints are still based on Envoy, but they are deployed and behave differently in Ambient. Waypoints are deployed per name space or per service account, allowing independent scaling of application pods and Waypoint pods. Also, Waypoints no longer handle both inbound and outbound traffic. In Ambient, Waypoints are producer or server side proxies. So they receive inbound traffic for that namespace or service account. So let's draw some arrows. In the basic case, client A's request is sent to the node local Ztunnel. That Ztunnel detects there's a Waypoint for the destination at B and directs the request through the namespace Waypoint before eventually reaching B. Once again, remember even though the namespace Waypoint serves both the client and the server application pods, it only handles inbound requests. For cross node, the first part of the request is the same. Request gets sent to the co-located Ztunnel for client A. Waypoint is detected for destination B, but then the request gets routed through B's node local Ztunnel. Now you might ask, what node is the Waypoint running on? The answer, it doesn't matter. The IP that Ztunnel retrieves for the Waypoint could refer to a service IP. In which case the Waypoint pod handling the request could be one of any number of replicas for that deployment. So I've covered calls between two ambient-enabled pods, but what about calls from outside the mesh? Pretty straightforward. The request comes in through an Ingress gateway and is sent through the destination's node local Ztunnel and eventually the destination app. And if we add a Waypoint into the path, the request is routed to the destination's Waypoint first, then the co-located Ztunnel and finally the destination app itself. So I've talked about Ingress, only reasonable to talk about egress, right? And that's a good question. Did I mention ambient is still pre-beta and egress is still in the design stages so you can get involved? There are weekly ambient workgroup meetings on Wednesdays, a design doc for ambient APIs and several channels on the Istio Slack to get involved. Thanks for listening, everyone. I hope the diagrams helped everyone better understand ambient a little more. Have any follow-up questions? I'm available on Slack as at GI Hansen. Hope everyone enjoys the rest of IstioCon.