This page describes the Google Kubernetes Engine (GKE) implementation of the Kubernetes Gateway API using the GKE Gateway controller. To deploy Gateways in GKE, see Deploying Gateways or Deploying multi-cluster Gateways.

The Gateway API is an open source standard for service networking. The Gateway API evolves the Ingress resource and improves upon it in the following ways:

  • Role-oriented: Gateway is composed of API resources that correspond to the organizational roles of cluster operator, developer, and infrastructure provider. This allows cluster operators to define how shared infrastructure can be used by many different and non-coordinating developer teams.

  • Portable: The Gateway API is an open source standard with many implementations. It's designed by using the concept of flexible conformance, which promotes a highly portable core API (like Ingress) that still has the flexibility and extensibility to support native capabilities of the environment and implementation. This enables the concepts and core resources to be consistent across implementations and environments, reducing complexity and increasing user familiarity.

  • Expressive: The Gateway API resources provide built-in functionality for header-based matching, traffic weighting, and other capabilities that are only possible in Ingress through custom annotations.

Gateway API resources

The Gateway API is a role-oriented resource model, designed for the personas who interact with Kubernetes networking. As shown by the following diagram, this model enables different non-coordinating service owners to share the same underlying network infrastructure safely in a way that centralizes policy and control for the platform administrator.

GKE provides Gateway classes. Cluster operators create
Gateway resources based on these classes. Application developers create
HTTPRoute resources that bind to Gateway resources.

The Gateway API contains the following resource types:

  • GatewayClass: Defines a cluster-scoped resource that's a template for creating load balancers in a cluster. GKE provides GatewayClasses that can be used in GKE clusters.
  • Gateway: Defines where and how the load balancers listen for traffic. Cluster operators create Gateways in their clusters based on a GatewayClass. GKE creates load balancers that implement the configuration defined in the Gateway resource.
  • HTTPRoute: Defines protocol-specific rules for routing requests from a Gateway to Kubernetes services. GKE supports HTTPRoutes for HTTP(S)-based traffic routing. Application developers create HTTPRoutes to expose their HTTP applications using Gateways.


A GatewayClass is a resource that defines a template for TCP/UDP (level 4) load balancers and HTTP(S) (level 7) load balancers in a Kubernetes cluster. GKE provides GatewayClasses as cluster-scoped resources. Cluster operators specify a GatewayClass when creating Gateways in their clusters.

The different GatewayClasses correspond to different Google Cloud load balancers. When you create a Gateway based on a GatewayClass, a corresponding load balancer is created to implement the specified configuration. Some GatewayClasses support multi-cluster load balancing.

The following table lists the GatewayClasses available in GKE clusters and their underlying load balancer type. For complete details on the GatewayClasses, see the GatewayClass capabilities and specifications.

Class name Description
gke-l7-rilb Regional internal HTTP(S) load balancers built on Internal HTTP(S) Load Balancing
gke-l7-gxlb Global external HTTP(S) load balancers built on External HTTP(S) Load Balancing
gke-l7-rilb-mc Multi-cluster regional load balancers built on Internal HTTP(S) Load Balancing
gke-l7-gxlb-mc Multi-cluster global load balancers built on External HTTP(S) Load Balancing

Each GatewayClass is subject to the limitations of the underlying load balancer.


Cluster operators create Gateways to define where and how the load balancers listen for traffic. Gateways take their behavior (that is, how they are implemented) from their associated GatewayClass.

The Gateway specification includes the GatewayClass for the Gateway, which ports and protocols to listen on, and which Routes can bind to the Gateway. A Gateway selects routes based on the Route metadata; specifically the kind, namespace, and labels of Route resources.

For an example of deploying a Gateway, see Deploying Gateways. For an example of deploying a multi-cluster Gateway, see Deploying multi-cluster Gateways.


An HTTPRoute defines how HTTP and HTTPS requests received by a Gateway are directed to Services. Application developers create HTTPRoutes to expose their applications through Gateways.

An HTTPRoute defines which Gateways it can route traffic from, which Services to route to, and rules that define what traffic the HTTPRoute matches. Gateway and Route binding is bidirectional, which means that both resources must select each other for them to bind. HTTPRoutes can match requests based on details in the request header.

A route can be bound to one or more Gateways, and a Gateway can bind to many routes.

GKE Gateway controller

The GKE Gateway controller is Google's implementation of the Gateway API for Cloud Load Balancing. Similar to the GKE Ingress controller, the Gateway controller watches a Kubernetes API for Gateway API resources and reconciles Cloud Load Balancing resources to implement the networking behavior specified by the Gateway resources.

There are two versions of the GKE Gateway controller:

  • Single-cluster: manages single-cluster Gateways for a single GKE cluster.
  • Multi-cluster: manages multi-cluster Gateways for one or more GKE clusters.

Both Gateway controllers are Google-hosted controllers that watch the Kubernetes API for GKE clusters. Unlike the GKE Ingress controller, the Gateway controllers are not hosted on GKE control planes or in the user project, enabling them to be more scalable and robust.

The Gateway controllers themselves are not a networking data plane and they do not process any traffic. They sit out of band from traffic and manage various data planes that process traffic. The following diagram shows the architecture of the single-cluster and multi-cluster GKE Gateway controllers. The underlying controller that is used depends on the GatewayClass of the deployed Gateway.

The multi-cluster and single-cluster Gateway controllers deploy and manage load balancers for GKE, but do not process network traffic themselves.

Controller Single-cluster Gateway controller Multi-cluster Gateway controller
Managed by Google Google
Cluster scope Single cluster Gateways Multi-cluster Gateways
Deployment location Deployed regionally in the same region as its GKE cluster. Deployed globally across multiple Google Cloud regions.
How to enable Enabled by default in GKE. Enabled through the Multi Cluster Ingress API and registration into a fleet. See Enabling multi-cluster Gateways.
Supported GatewayClasses
  • gke-l7-rilb
  • gke-l7-gxlb
  • gke-l7-rilb-mc
  • gke-l7-gxlb-mc

You can use multiple Gateway controllers, including controllers not provided by Google, in a GKE cluster simultaneously. Every GatewayClass is supported by one and only one Gateway controller, which enables single and multi-cluster load balancing to be used simultaneously.

Comparison of Ingress and Gateway

Gateway and Ingress are both open source standards for routing traffic. Gateway was designed by the Kubernetes community, drawing on lessons learned from the Ingress and the service mesh ecosystems. Gateway is an evolution of Ingress that provides the same function, delivered as a superset of the Ingress capabilities. Both can be used simultaneously without conflict, though over time Gateway and Route resources will deliver more functionality not available in Ingress, compelling users to start using Gateway where they might have previously used Ingress.

The Gateway API standard is currently in the v1Alpha1 stage which means that it is for experimental and evaluation use only at this time. Breaking API changes are planned before the Beta of the Gateway API. Similarly, the GKE Gateway controller is also in Preview, intended only for experimentation. Your feedback is critical to the evolution of the GKE Gateway controller and will help us reach general availability. Feel free to reach out to with feedback and questions. We are looking forward to hearing from you.


All Compute Engine resources deployed through the Gateway controller are charged against the project in which your GKE clusters reside. The single-cluster Gateway controller is offered at no additional charge as a part of GKE Standard and Autopilot pricing. You can use the multi-cluster Gateway controller without additional charge during Preview. For more details on GKE multi-cluster Gateway controller pricing, see Enabling multi-cluster Gateways.

What's next