East-west and waypoints
Manage routing and apply policies within your ambient mesh.
In-mesh routing is facilitated by ztunnels, waypoint proxies, and east-west gateways (in multicluster setups). For more information about how routing works in an ambient mesh, see the traffic management overview.
Set up in-mesh routing
Set up in-mesh routing in your ambient mesh in the following ways.
Ztunnels: You initially create ztunnels when you follow the steps to use the Gloo Operator or Helm to set up an ambient mesh. Then, to enable in-mesh routing, simply label your service namespaces to be included in the ambient mesh. The label instructs the ztunnel instance that is co-located on the same node to configure a ztunnel socket on the app pod. To get started, see the sample apps guide.
East-west gateways (multicluster only): In a multicluster environment, start by following the steps to use the Gloo Operator or Helm to create a multicluster ambient mesh. These steps involve peering the cluster networks, and deploying the east-west gateway to each cluster.
Apply Layer 7 policies
About waypoints
When you are ready to begin applying L7 policies, the recommended approach is to deploy a waypoint proxy for a service namespace and enroll the whole namespace to use that waypoint by applying the istio.io/use-waypoint=waypoint namespace label. After you enroll a namespace to use a waypoint, any requests from any pods in the ambient mesh to any service that runs in that namespace is routed through the waypoint proxy for L7 processing and policy enforcement.
For more granular control, you can add a waypoint proxy to a particular service or pod. This can be useful if you only need L7 features for some services in a namespace, but is more cumbersome to manage.
If you have multiple instances of the same app across a multicluster ambient mesh, be sure to deploy a waypoint to the namespace in each cluster that the service instances exist in.
To set up waypoint proxies, you can use Gloo Gateway, or use community ambient mesh directly.
Gloo Gateway as a waypoint proxy (recommended)
Use Gloo Gateway as the waypoint proxy for apps in your ambient mesh. Gloo Gateway is fully conformant with the Kubernetes Gateway API and extends its functionality with Solo’s custom Gateway APIs, such as RouteOption, VirtualHostOption, Upstreams, RateLimitConfig, or AuthConfig. These resources help to centrally configure routing, security, and resiliency rules for a specific component, such as a host, route, or gateway listener.
To get started, follow the Gloo Gateway as a waypoint proxy guide in the Gloo Gateway docs. This guide includes steps to use Gloo Gateway to create waypoint proxies with the gloo-waypoint Gateway class, and apply example L7 policies to the waypoint.
Gloo Gateway as a waypoint proxy is supported only for single-cluster ambient mesh setups, and cannot currently be used in multicluster ambient meshes.
Community ambient mesh
To use the Gateway class provided by community ambient mesh to create waypoint proxies, istio-waypoint, see Deploy a waypoint proxy in the community ambient mesh docs.
For an example of applying an authorization policy at L7, see Authorization policy with waypoint proxies in the community ambient mesh docs.
Versions 1.25 and later of the Solo distribution of Istio include support for automatic waypoint deployment. Instead of manually creating a waypoint proxy resource, and then labeling a namespace, service, or service entry to use that waypoint, you can simply label the namespace, service, or service entry with istio.io/usewaypoint=auto. Istiod automatically creates the appropriate waypoint with the istio-waypoint Gateway class and applies it to your target resource. To avoid collisions, only apply this label at either the namespace level or at the level of individual services and service entries, but not both for a given service.
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.
The istio.io/ingress-use-waypoint=true label is supported only in community ambient mesh versions of the waypoint proxy, and is not currently supported when using Gloo Gateway as the waypoint proxy.
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.