Expose GKE Services with the Kubernetes Gateway API (2026)

The Kubernetes Gateway API doesn’t actually replace Ingress; it’s a more expressive, role-oriented successor that unifies routing for various network protocols.

Let’s see the Gateway API in action. Imagine you have a simple web application deployed in GKE, and you want to expose it to the internet.

First, you need a GatewayClass. This is a cluster-wide resource that defines the capabilities of a gateway implementation. For GKE, you’ll typically use the gke-l7-global-external-managed class for global external HTTP(S) load balancing.

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: gke-l7-global-external-managed
spec:
  controllerName: networking.gke.io/gateway

Next, you create a Gateway resource. This is where you specify the details of your load balancer, like its name, the GatewayClass to use, and what IP address and ports it should listen on.

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: my-gateway
  namespace: default
spec:
  gatewayClassName: gke-l7-global-external-managed
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      namespaces:
        from: Same
  - name: https
    protocol: HTTPS
    port: 443
    tls:
      mode: MUTUAL
      certificateRefs:
      - name: my-cert
        namespace: cert-manager # Assuming cert-manager is used for TLS
    allowedRoutes:
      namespaces:
        from: Same

Notice the allowedRoutes.namespaces.from: Same. This means this Gateway will only accept routing rules defined in the same namespace (default in this case). You can also set it to All to allow routes from any namespace.

Now, to actually route traffic to your application, you define an HTTPRoute. This resource specifies how to match incoming requests and where to send them.

Let’s say you have a deployment named my-app-deployment in the default namespace, exposed by a Service named my-app-service on port 8080.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-app-route
  namespace: default
spec:
  parentRefs:
  - name: my-gateway
    namespace: default
  hostnames:
  - "example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: "/"
    backendRefs:
    - name: my-app-service
      port: 8080

When you apply these resources, GKE provisions a Google Cloud HTTP(S) Load Balancer. The Gateway resource configures the load balancer’s frontend (IP address, ports, TLS settings), and the HTTPRoute configures the backend services and URL routing rules. The hostnames field in the HTTPRoute allows you to specify which domain names this route applies to, enabling host-based routing.

The core problem the Gateway API solves is the lack of extensibility and role separation in the older Ingress API. Ingress was often a monolithic resource managed by developers, leading to conflicts and a lack of clear ownership. The Gateway API introduces distinct resource types (GatewayClass, Gateway, HTTPRoute, TCPRoute, TLSRoute, UDPRoute, etc.) that map to specific roles: infrastructure providers manage GatewayClass and Gateway (the load balancer infrastructure), while application developers manage HTTPRoute and other route types (the traffic routing logic). This separation of concerns makes it much easier to manage complex routing configurations and delegate responsibilities.

A subtle but powerful aspect of the Gateway API is its support for advanced traffic management features natively. For example, you can define weighted routing for canary deployments or A/B testing directly within an HTTPRoute without needing a separate service mesh. You specify this by adding multiple backendRefs to a rule, each with a weight:

  rules:
  - matches:
    - path:
        type: PathPrefix
        value: "/"
    filters:
    - type: RequestRedirect
      requestRedirect:
        scheme: https
        statusCode: 301
    backendRefs:
    - name: my-app-v1-service
      port: 8080
      weight: 90
    - name: my-app-v2-service
      port: 8080
      weight: 10

This configuration directs 90% of traffic to my-app-v1-service and 10% to my-app-v2-service, all managed by the GKE load balancer. The Gateway API’s flexibility means you can also perform request header manipulation, query parameter matching, and more, directly at the load balancer level.

The next concept you’ll likely explore is managing TLS certificates more dynamically, perhaps with integration into cert-manager for automated certificate issuance and renewal for your Gateway’s HTTPS listener.