Ingress traffic to your GKE fleet with the Multi-cluster Gateway controller, now GA
Pierre-Louis Gingembre
Senior Product Manager
Bowei Du
Senior Staff Software Engineer, Cloud Networking
Building distributed applications has become mainstream for many businesses that rely on Google Kubernetes Engine (GKE). Over the past few years, we have launched features to help GKE users manage fleets of clusters, providing capabilities like multi-cluster Ingress (for North-South traffic) and multi-cluster Services (for East-West traffic).
At the same time, the Kubernetes community created the Gateway API, a declarative, extensible, role-oriented and portable service-networking API. We announced our first implementation of the Kubernetes Gateway API in December 2022, supporting single-cluster GKE deployments.
Today, we are excited to announce the general availability of the Multi-cluster Gateway controller for GKE, which natively supports the deployment of a unified Application Load Balancer for a fleet of GKE clusters using the Kubernetes Gateway API. Now, GKE shops can implement sophisticated patterns such as blue-green deployments or geo-distributed applications while keeping their most valuable assets protected with advanced security capabilities integrated with our application load balancers.
What is the GKE multi-cluster Gateway controller?
The GKE Gateway controller is Google’s implementation of the Gateway API for Cloud Load Balancing. Like any other Kubernetes controller, the Gateway controller watches for Gateway API resources and creates managed Cloud Load Balancing resources to implement the networking behavior specified by the Gateway resources.
The multi-cluster Gateway controller is a multi-tenant Google-hosted controller that does not run on GKE control plane nodes, benefiting from the large scale and distributed Google Cloud infrastructure for more availability and robustness.
Get started with multi-cluster Gateway
Multi-cluster Gateways are not fundamentally different from single-cluster Gateways, except that they reference services deployed across multiple clusters (multi-cluster Services) to address today’s application availability requirements.
Whether you want to ensure that you have enough capacity to serve your clients, or you want to provide an infrastructure for multiple teams with blue-green deployments, or you even want to ensure your application remains available in the case of a region downtime, multi-cluster Gateway and Services become essential components of your application infrastructure design.
Multi-cluster Gateway is included with GKE Enterprise at no extra cost, and customers using GKE Standard edition can also benefit from it as a standalone solution. Both editions will allow customers to use multi-cluster Gateways with GKE Autopilot and GKE Standard clusters.
Supported Cloud Load Balancers
Within Google Cloud, Gateway API resources allow us to abstract the details of Cloud Load Balancing and use a Kubernetes-native language to express the routing intent for one or many applications.
As of today, multi-cluster Gateway supports the following Application Load Balancers, helping customers with a variety of use cases:
To know more about each of these GatewayClass capabilities, please see this guide.
Optimize global and regional routing in your GKE fleet
One of the benefits of the Gateway API is its expressiveness in terms of routing and traffic management, and our implementation is no exception. Using backend attributes like weights or route rule filters, you can customize your Gateways to match on specific HTTP paths or headers, and apply sophisticated routing policies to a list of backends running in multiple clusters and/or regions.
Leveraging the power of Cloud Load Balancers, GKE platform administrators can offer their application teams a set of traffic management capabilities that will make their services more effective, with higher availability. Read on for a few examples.
Gradual rollouts (blue-green upgrades or deployments)
Platform teams can qualify a new GKE version on a new cluster and gradually migrate the workloads and services over to the new cluster, performing what is known as a blue-green upgrade. Using traffic splitting across multiple clusters dramatically simplifies operations and helps ensure a smooth GKE upgrade process for platform and application teams.
Application teams can also benefit from a multi-cluster architecture and use a blue-green deployment strategy with new versions of their applications. That way, version one of the application runs on the "blue" cluster and version two of the application on the "green" cluster. The application team can decide to switch traffic from v1 to v2 based on a specific path or header, until the application is fully migrated to the new version.
Last, in the event that an application team needs to mirror traffic that was sent to a service running in a first cluster to another cluster (e.g., for compliance reasons, or to analyze or troubleshoot client traffic), they can use the multi-cluster Gateway to mirror that traffic and send it to the production cluster and an "audit" cluster at the same time.
These capabilities are available with regional and global multi-cluster Gateways, whether the clusters are deployed in different zones in the same region, or across multiple regions.
Distributed application with proximity routing
Customers running distributed applications across multiple regions can use a global external multi-cluster Gateway with an anycast IP to attract client traffic to the closest Google edge point of presence (PoP) from the client, and deliver the traffic to the closest regional backends that are available to any of the clusters in the fleet.
For customers in regulated areas that require traffic to remain local to the region, a regional external multi-cluster Gateway with a regional IP can be used to help improve compliance with local regulations. In this case, client traffic is routed over the internet to the destination region where the Gateway IP is announced, and the traffic is routed only to regional backends.
Capacity-based load balancing
Finally, customers building applications that require traffic throttling to ensure the good health of their services can define the service capacity (max request per endpoint), and load balance traffic based on the number of requests being sent to the backend pods. The service can be fully distributed across multiple clusters, and the multi-cluster Gateway ensures optimal distribution of traffic across all backend pods, and spill over to other regions when the number of requests is higher than the defined service capacity.
Secure your exposed applications with a multi-cluster Gateway
Distributed internet-facing applications deployed in a fleet of GKE clusters are prone to DDoS attacks and other security threats and require extra layers of security to help ensure the privacy and integrity of their traffic. Multi-cluster Gateway is a GKE-managed implementation of Application Load Balancers and benefits from all the advanced security features of our load balancers. Read on to learn more.
Encrypt with TLS for confidentiality and integrity
A first step in your security strategy for your web applications is to define your SSL policy, so that undesired traffic is dropped at the Gateway level and not by the backend pods themselves; this helps to proactively avoid congestion at the application level.
Then, to ensure that HTTPS traffic can be trusted, client-to-Gateway and Gateway-to-backends traffic can rely on TLS certificates, either self-managed or Google-managed. You have the option to store your certificates either as secrets in your GKE clusters, which requires some coordination in a fleet environment, or directly at the load balancer level. A multi-cluster Gateway supports up to 15 certificates locally stored on the Gateway; to go beyond that, you can use Certificate Manager to support up to 1 million certificates to secure your application traffic.
Using a combination of policies and filters to redirect traffic from HTTP to HTTPS, application teams can help ensure that traffic is encrypted end to end.
Control and protect your Gateway backends with Cloud Armor
In many cases, security teams require all platforms and applications to enforce a default security policy to prevent unwanted inbound traffic. Some organizations that only serve in one geolocation may want to restrict application access to IP addresses only from this location. Likewise, some organizations may want to block malicious IP addresses to avoid DDoS attacks. In addition, internet-facing applications can be subject to sophisticated application-layer attacks such as SQLi, XSS, etc. Application teams can use a web application firewall to help mitigate those attacks.
Cloud Armor is a multi-layer web application firewall that can help organizations control and protect the crown jewels running in a GKE fleet by filtering traffic at the network level, but also by performing deep packet inspection at the application level with fine-grained security policies.
Platform and application teams can use Multi-cluster Gateway to add this security control to their application, by setting up a backend policy and reference their Gateway.
Authenticate and authorize traffic with Identity-Aware Proxy
With proper network-level controls in place (e.g., SSL policies, TLS certificates, Cloud Armor), your application team may want to add another layer of authentication and authorization based on user identity for your HTTPS applications.
Identity-Aware Proxy provides this access control right at the multi-cluster Gateway level. This helps ensure that access to the backends running in your fleet of GKE clusters has been verified by checking who the user is (via Google account credentials) and their role and permissions (using Identity and Access Management).
Once again, by using a backend policy attached to the backend services, application teams can set the right level of access to their applications, securely expose applications to end users (or systems), and log access to the applications based on users’ identity.
What’s next?
There are many resources available to learn about the Gateway API and how to use the GKE Gateway controller in the context of a GKE fleet. If you want to know more about the Google implementation and how it could benefit your organization, you can check out these links:
We are also coming to KubeCon NA in Chicago in a few days!
Feel free to reach out to our amazing team and stop by our booth, learn about our sessions, and request a meeting with us to discuss your use case(s) and see how Google can help you. We will be hosting many lightning talks at our booth, including one on multi-cluster Gateway on Wednesday, November 8 at 2:00 pm, and how it can help you improve the availability of your distributed applications.
Finally, there are plenty of breakout sessions on Gateway API at KubeCon, in the context of load balancers for Kubernetes, but also with the recent GAMMA initiative to support service mesh use cases. Check those sessions out and learn more about this very collaborative networking API:
- Gateway API: The Most Collaborative API in Kubernetes History Is GA - Rob Scott, Google & Nick Young, Isovalent
- Modern Load Balancing, Improving Application's Resource Availability and Performance - Antonio Ojea & Gerrit DeWitt, Google
- Istio: The Past, Present and Future of the Project and Community - Louis Ryan, solo.io & John Howard, Google (Description: Gateway API)
