This document describes how multi-cluster Gateways operate withinGoogle Kubernetes Engine (GKE). Multi-cluster Gateways are a powerful networkingsolution that let you manage traffic for services deployed across multipleGKE clusters.

This document is for Cloud architects and Networking specialists whodesign and architect their organization's network. To learn more about commonroles and example tasks that we reference in Google Cloud content, seeCommon GKE Enterprise user roles andtasks.

Overview

Multi-cluster Gateway is configured by using the Kubernetes Gateway APIresources. The GKE Gateway controller watches these resources(Gateway, HTTPRoute) and automatically provisions and maintains the requiredGoogle Cloud global load-balancing infrastructure. This infrastructure provides advancedtraffic management for services deployed across multiple GKEclusters within a fleet. Multi-cluster Gateways uses Google Cloud's globalload-balancing infrastructure to provide a single, unified entry point for yourapplications. This approach has the following benefits:

• Simplifies management
• Improves reliability
• Enables advanced traffic management capabilities

Traffic management capabilities

Multi-cluster Gateways provide you with advanced capabilities to manage trafficacross multiple clusters. You can implement sophisticated routing strategies,such as phased rollouts and blue-green strategies, to safely deploy changes. Forfine-grained control, you can use header-based matching to test changes with asmall percentage of traffic, or split traffic by weight to gradually shiftrequests between different cluster backends.

Multi-cluster Gateways also let you mirror traffic, which sends a copy oflive user requests to a new service to test performance without impacting users.To ensure reliability and prevent overloads, multi-cluster Gateways supporthealth-based failover and capacity-based load balancing, which distributesrequests based on the defined capacity of your services.

How multi-cluster Gateway works

All GKE clusters that participate in a multi-cluster Gateway setupmust be registered to a fleet. A fleet provides a logical grouping of clusters,which enables consistent management and communication across the clusters. OneGKE cluster within the fleet is designated as theconfig cluster.

Theconfig cluster acts as a centralized control point for yourmulti-cluster Gateway configuration. You deploy all multi-cluster Gateway APIresources, such asGateway andHTTPRoute, only to this designated cluster.The GKE Gateway controllerwatches the Kubernetes API server of the config cluster for these resources.

To choose a config cluster, consider ahighlyavailableGKE cluster, such as a regional cluster. This ensures thatupdates to your Gateway API resources can becontinuously reconciled by the controller.

The multi-cluster Gateway controller uses multi-cluster Services (MCS) todiscover and access Kubernetes Services across multiple GKEclusters within a fleet. MCS is a GKE feature that enables service discovery and connectivity between Services that run in different GKE clusters within a fleet.

MCG uses MCS to discover which Services are available in which clusters in orderto route external traffic to the Services. The MCG controller uses MCS APIresources to group Pods into a single Service that is addressable and spansmultiple clusters.

Based on the configurations that you defined in the Gateway API resources, theGKE Gateway controller provides either an externalApplication Load Balancer or an internal Application Load Balancer. This loadbalancer serves as the frontend for your application, and distributes trafficdirectly to the healthy Pods across your fleet, regardless of their location.

The following high-level steps describe the process to deploy a multi-clusterGateway:

1. Define a Gateway: in a multi-cluster Gateway setup, you create a Gatewayresource that defines the entry point for your traffic in the configcluster. The Gateway resource specifies a GatewayClass, which is a templatefor a particular type of load balancer, such as aGlobal external Application Load Balancer or a Regional internal Application Load Balancer. InGKE, the following GatewayClasses deploy multi-clusterGateways:

   • gke-l7-global-external-managed-mc: provisions a Global external Application Load Balancer.
   • gke-l7-regional-external-managed-mc: provisions a Regional external Application Load Balancer.
   • gke-l7-cross-regional-internal-managed-mc: provisions a Internal Application Load Balancer.
   • gke-l7-rilb-mc: provisions a Internal Application Load Balancer.
   • gke-l7-gxlb-mc: provisions a Classic Application Load Balancer.

   The Gateway also defines how the load balancer listens for incoming traffic byspecifying which network listeners (ports and protocols) to expose. For moreinformation about Gateway Classes that GKE supports, seeMulti-clusterServices.

2. Attach HTTPRoutes to the Gateway: HTTPRoute resources define howincoming HTTP/S traffic is routed to specific backend services. HTTPRoutesare attached to Gateway resources and specify rules based on hostnames,paths, headers, and more. HTTPRoute also supports advanced trafficmanagement features like traffic splitting and traffic mirroring.

3. Create load balancer: when you deploy Gateway and HTTPRoute resources,the GKE Gateway controller interprets these API objects and,in turn, dynamically configures the necessary Google Cloud loadbalancing infrastructure. The load balancer then directs traffic to thecorrect Pods, regardless of which cluster the Pods are in. This processprovides a highly efficient and scalable way to route traffic.

Traffic flow

The following diagram illustrates how a multi-cluster Gateway works as acentralized load balancer for applications that run across twoGKE clusters in different regions:

The load balancer's behavior is configured based on the rules defined in yourHTTPRoute resources. When user traffic arrives at the IP address of theprovisioned Google Cloud load balancer (as defined by your Gateway resource),the load balancer, which is a Google-managed proxy, routes the traffic. This proxy (either a Google Front End proxy or aregional proxy) directs the traffic to the appropriate backend service endpointwithin the correct GKE cluster, based on the following criteria:

• Health checks
• Traffic splitting rules
• Capacity

The traffic flows directly to the optimal Pod in the selected cluster.

What's next

• Learn how toenable multi-cluster Gateways.
• Read an overview on howGateways work in GKE.