Overview of ingress gateways

Learn about the options to deploy an ingress gateway for an ambient service mesh, including the Kubernetes Gateway API and the Istio API.

A gateway is a proxy at the edge of an ambient mesh that can be used to allow traffic to ingress or egress.

The options to deploy an ingress gateway vary based on the traffic management API. Although you can use either the Kubernetes Gateway API or the Istio API, the Kubernetes Gateway API is the recommended method for ambient service meshes. Many Solo Enterprise for Istio guides, such as setting up multicluster peering for a cross-cluster ambient mesh, use the Kubernetes Gateway API only.

Kubernetes Gateway API ingress gateways

To use the Kubernetes Gateway API custom resources to configure traffic management in your service mesh, you can deploy Gateway resources that expose your services. Note that using the Kubernetes Gateway API is the recommended method for ambient service meshes. For more information about using the Gateway API in Istio, see this blog post.

To set up an ingress gateway, you can use Solo Enterprise for agentgateway, Solo Enterprise for kgateway, or the native Kubernetes Gateway API directly.

Solo Enterprise for agentgateway

Use Solo Enterprise for agentgateway as the ingress gateway for your ambient mesh. Agentgateway is fully conformant with the Kubernetes Gateway API and uses the enterprise-agentgateway GatewayClass and standard HTTPRoute resources to route external traffic to services in your ambient mesh. Agentgateway also has native support for routing to LLM providers, MCP servers, and A2A agents.

To get started, follow the Ingress gateway with agentgateway guide to install agentgateway and expose a service through the gateway.

Note

This feature requires an Enterprise-level license for Solo Enterprise for Istio and a Solo Enterprise for agentgateway license. Contact your account representative to obtain valid licenses.

Solo Enterprise for kgateway

Use Solo Enterprise for kgateway as the ingress gateway for your ambient mesh. Solo Enterprise for kgateway 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 Ingress to ambient mesh guide in the Solo Enterprise for kgateway docs to integrate Solo Enterprise for kgateway with your ambient mesh. This guide includes steps to expose the Bookinfo product page app on the gateway proxy.

Note

Using Solo Enterprise for kgateway as an ingress gateway to a single-cluster ambient mesh setup does not require a Solo Enterprise for kgateway license. However, using Solo Enterprise for kgateway as an ingress gateway to a multicluster ambient mesh requires an Enterprise level license key for both Solo Enterprise for Istio and Solo Enterprise for kgateway.

Native Kubernetes Gateway API

To directly create an ingress gateway by using the native Kubernetes Gateway API, you can follow the Kubernetes Gateway API guide.

Istio networking API ingress gateways

Warning

This method is not recommended for ambient. Some features, such as using destination rules to define subsets, do not work across clusters in a multicluster ambient mesh setup.

To get started with the Istio networking API, deploy an Istio ingress gateway by using Helm, and use the Istio networking API resources, such as Istio Gateways and VirtualServices, to route to apps.

Third-party ingress gateways

If you use a gateway solution in your cluster that is non-native to the Kubernetes Gateway API or the Istio networking API, such as an nginx ingress gateway, you can follow the third-party gateway guide. Note that this integration cannot be used for cloud platform load balancers.

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.

If you use a flat network setup for your multicluster ambient mesh, and want to apply the istio.io/ingress-use-waypoint=true label to a service that is exposed globally across clusters in the mesh, you must maintain namespace sameness for the service instances. In other words, you must maintain identical manifests, including labels, for each service instance in the same namespace of each cluster. If one of the service instances in any cluster has the istio.io/ingress-use-waypoint=true label, the global service uses the waypoint for ingress traffic.

In a peered multicluster environment (east-west gateway peering with auto-generated ServiceEntry and WorkloadEntry resources), you only need to set istio.io/ingress-use-waypoint on the Service or namespace in the cluster where the workload runs. The peering controller propagates it automatically to connected clusters, so ingress gateways throughout the mesh route traffic through the waypoint without additional configuration.

The label uses the following precedence order:

istio.io/ingress-use-waypoint label on the Kubernetes Service (highest priority). Setting the label to false explicitly disables waypoint routing even if the namespace has the label set to true.
istio.io/ingress-use-waypoint label on the namespace.
If no local Service or namespace label is set, the label is inherited from remote services. If any remote cluster has the label set to true on its service, the observing cluster treats the service as waypoint-enabled for ingress traffic.

Agentgateway ingress