Skip to content

Overview of ingress gateways

Page as Markdown 

    

  
  


              
            

          

          
          
Deploy and configure ingress gateways in ambient mesh using the Kubernetes Gateway API to manage traffic at the cluster edge.

          
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.


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.


kgateway
    
Use kgateway as the ingress gateway for your ambient mesh. kgateway is a CNCF project built on Envoy and configured with the Kubernetes Gateway API. It offers first-class APIs for rate limiting, external auth, header manipulation, and request transformations. To get started, follow the kgateway ingress guide.


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.
    • 



In a peered multicluster environment with Solo Enterprise for Istio (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:


    

  1. 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.
    2. 

  2. istio.io/ingress-use-waypoint label on the namespace.
    3. 

  3. 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.
    4. 



        

        
kgateway