After you add apps to your ambient mesh, you can configure routing to and from the in-mesh apps, and set up specific traffic management rules to apply to request routing.

Routing components

In-mesh routing is facilitated by ztunnels, waypoint proxies, east-west gateways (in multicluster setups), and optionally ingress and egress gateways. For more information, see the ambient component overview.

Ztunnels

The easiest way to add services to your ambient mesh and establish secure routing within your service mesh is by labeling the service’s namespace. The label instructs the ztunnel instance that is co-located on the same node to configure a ztunnel socket on the app pod. The socket secures traffic to and from the app via mutual TLS. Ztunnels are scoped to only process traffic on L4. That way, it can safely operate as a shared component while you try out an ambient mesh.

Waypoint proxies

After you add your apps to the ambient mesh to set up in-mesh routing via ztunnels, you can decide whether you need waypoint proxies for policy application on L7. Deploying waypoint proxies might be the second step you take to shift your policy-driven routing decisions to the ambient mesh configuration.

If your app requires any of the following L7 policies and routing capabilities, you must deploy a waypoint proxy for your app.

  • Traffic management: HTTP routing, HTTP load balancing, circuit breaking, rate limiting, fault injection, retries, and timeouts
  • Security: Authorization policies based on L7 primitives, such as request types or HTTP headers
  • Observability: HTTP metrics, access logging, and tracing

East-west gateways

In a multicluster ambient mesh, you deploy an east-west gateway to each cluster in the mesh. The east-west gateways facilitate traffic routing across clusters in the mesh. For example, if your target app is in a different cluster network than the ingress gateway or the source in-mesh app, the request is first routed to the east-west gateway that is located on the target cluster. Then, the east-west gateway forwards the request to the target app’s ztunnel socket.

For this reason, it is not recommended to apply any kind of routing logic or policies to east-west gateways. After you create the east-west gateways in a multicluster ambient mesh, you can forget about them.

Ingress and egress gateways

For other routing configurations, such as managing traffic requests either from clients outside the ambient mesh or to services outside the ambient mesh, you might configure ingress or egress gateways. In a typical ambient mesh setup, the ingress or egress gateway determines basic routing rules, such as backend destination selection, but can also apply additional policies to the traffic entering and leaving the mesh. However, keep in mind that these gateway components are not required to configure routing within the ambient mesh.

Traffic request flows

Single-cluster setups

In a single cluster setup, a traffic request to your app from a client outside of the mesh is first received through your ingress gateway. The ingress gateway routes the request to the ztunnel socket of the target app pod. The socket is configured by the ztunnel instance that is located on the same node as the app pod. It secures the traffic request before traffic is forwarded within the ambient mesh. If the target app has Layer 7 (L7) policies that are applied by a waypoint proxy, the ingress gateway sends the request first to the waypoint, which enforces the L7 policy and collects L7 metrics before forwarding the request to the app’s ztunnel socket.

Figure: Traffic flow through a single-cluster ambient mesh.
Figure: Traffic flow through a single-cluster ambient mesh.

Multicluster setups

In a multicluster setup, a traffic request to your app from a client outside of the multicluster mesh is first received through your ingress gateway.

  • If the target app is in the same cluster network as the ingress gateway, the ingress gateway routes the request to the ztunnel socket of the app pod.
  • If the target app is in a different cluster network than the ingress gateway, the ingress gateway first routes the request to the east-west gateway that is located on the target cluster. Then, the east-west gateway forwards the request to the target app’s ztunnel socket. Traffic between gateways and ztunnel sockets is secured via mTLS by default.

If the target app has Layer 7 policies that are applied by a waypoint proxy, the ingress or east-west gateway sends the request first to the waypoint, which enforces the L7 policy and collects L7 metrics before forwarding the request to the app’s ztunnel socket.

Figure: Traffic flow through a multicluster ambient mesh.
Figure: Traffic flow through a multicluster ambient mesh.

Using ingress gateways in combination with waypoints

In an ambient service mesh, both gateways and waypoint proxies can be used to route traffic, apply traffic, security, and resiliency policies, and perform authentication.

When you have a waypoint proxy for a target app, in-mesh traffic requests are always routed to the waypoint proxy for the target app first. When one in-mesh app sends a request to another in-mesh app that has a waypoint, the traffic request is sent to the waypoint proxy instead of directly to the backend app.

However, by default in Istio, ingress gateways send incoming traffic requests to backend destinations directly, even if a destination uses a waypoint. This default behavior helps prevent double handling; for example, if you created rules for traffic splitting on both the ingress gateway and a waypoint proxy, this behavior ensures that the rules are not applied twice.

This behavior requires you to add certain policies on both the gateway and the waypoint. To prevent this, you can instead enable ingress waypoint routing on a service by labeling it with istio.io/ingress-use-waypoint=true. This label configures the ingress gateway to send traffic requests to the configured waypoint, and not directly to the destination service.

If you use this service label for your waypoint-enabled services, the following approach is recommended as the ideal architecture for a fully-functioning ambient service mesh:

  • Gateways: Apply minimal routing logic, such as through HTTPRoutes, that is sufficient only for selecting a backend app. Avoid applying policies to gateways, except for policies that must be applied at the edge, such as rate limiting or user authentication.
  • Waypoints: Apply all other routing and policy logic.

Get started with request routing

You can set up gateways and waypoints to enable request routing, and use HTTPRoutes to determine how destinations are selected for traffic request to and from apps in your mesh.

Ingress gateways: To set up basic L4 routing to your apps, you can choose an ingress gateway from the available options in the Expose apps with an ingress gateway guide.

East-west gateways and waypoints: To manage routing and apply policies within your ambient mesh, you can review the recommended in-mesh routing setups in the Control in-mesh traffic with east-west gateways and waypoints guide.

Egress gateways: To allow apps in your mesh to send traffic requests to an external service, follow the steps in Control traffic with an egress gateway. Note that the egress gateway is created as a waypoint proxy for an external service.

Get started with traffic management

After you set up destination selection with request routing, you can further modify how the traffic requests are routed to apps by defining routing rules in your HTTPRoutes. Consult the traffic management guides in the community ambient mesh docs to see examples for traffic splitting, mirroring, redirects and rewrites, and more.