Google Kubernetes Engine Gateway controller is now GA for single cluster deployments

Back in July, the Kubernetes community announced the graduation of the Gateway API to beta, a big milestone for the group of people shaping the future of this networking API that defines the routing intent into a Kubernetes cluster, and even beyond, with service mesh capabilities through the GAMMA initiative. The Gateway API is the next generation of the Ingress API, with a broader scope and more use cases that can be addressed with it.

Today, we’re excited to announce the General Availability of the Google Kubernetes Engine (GKE) Gateway controller, Google Cloud’s implementation of the Gateway API, supporting single cluster deployments, in GKE 1.24+ clusters. 

A quick recap of the Gateway API

Platform operators are faced with the dual challenge of having to provide flexibility to developers consuming networking infrastructure while having to maintain control and consistency across teams.

Kubernetes is solving the need for the separation of duties between service owners and platform administrators with the Gateway API, which provides an open source, role-based standard for service networking. It is a structured way to describe network services consistently across a Kubernetes implementation, cross-tenants and cross-namespaces and be able to match the network resource with the appropriate roles. 

Previously each service owner made individual decisions about their choice of ingress, which could lead to inconsistencies in production due to the multitude of available solutions.

With the Gateway API, platform administrators can define policies and constraints on the networking infrastructure, and allow different teams or organizations to consume the shared networking services such as L4 and L7 load balancing while maintaining consistency and control.

The GKE Gateway controller

The GKE Gateway controller is Google Cloud’s implementation of the Gateway API for GKE clusters. It is a fully managed service with deep integration with GKE, enabling platform operators to manage internal and external HTTP(S) load balancing using an expressive and extensible API. Based on years of experience managing the GKE Ingress controller, we’ve engineered a controller that leverages the power of Google Cloud infrastructure and provides a highly redundant, scalable and multi-tenant service to manage load balancers for single- and multi-GKE cluster deployments, with centralized policy and control.

Advanced capabilities for platform administrators and service owners

Thanks to the flexibility and separation of concerns built into the Gateway API, GKE platform administrators can now attach a secure shared load balancer to a GKE cluster and let service owners define routing and traffic management policies to access their applications running in this multitenant GKE cluster.

By using the Gateway API with GKE, platform administrators and service owners get the following capabilities:

Shared Gateway for many routes/tenants - One of the pain points expressed by many customers regarding the Ingress implementation is the proliferation of load balancers as the cluster grows with more namespaces. By defining a single Gateway for a cluster, a single shared load balancer is created for the entire cluster, and each application team can define their own Routes to express the expected routing behavior for their namespace. Each Route is attached to a Gateway, which keeps the forwarding decision central without compromising the distributed nature of the Kubernetes configuration per namespace.

Global external and Regional Internal load balancing - The GKE Gateway controller comes by default with two GatewayClasses, one for the global external HTTP(S) load balancer (classic) (gke-l7-gxlb) and one for the regional internal HTTP(S) load balancer (gke-l7-rilb). Each GatewayClass can be used independently in the same GKE cluster to route traffic from the internet or from internal resources inside or connected to a VPC. 

End-to-end encryption at scale - The Gateway API defines how TLS can be implemented to provide a secure connection between the client and the gateway, as well as between the gateway and backend services. The GKE Gateway controller not only supports TLS for downstream and upstream traffic, but it does it at an unprecedented scale with an integration with Certificate Manager, to provide up to a million certificates for applications running in GKE. Google-managed SSL certificates or Kubernetes secrets can also be used as alternative options to secure connections between clients and the Gateway. As for upstream traffic (between the Gateway and backend services), TLS can also be used to ensure end-to-end encryption between clients and backend services.

Customized backend service properties - Many of our customers have particular needs when it comes to load balancing and especially how they want to maintain sessions with the backend services, or a custom health check. With a simple Policy attached to a Service, you can now define how session affinity or connection draining timeout should be handled, as well as custom health checks for applications that require a different port and/or path.

Advanced traffic management - The Google Cloud implementation of the Gateway API also gives you the ability to define how traffic should be handled from clients to applications. First of all, you can finally do something that was missing so much with Ingress: cross-namespace routing. But also, by leveraging the rich portfolio of features that the Google Cloud load balancers provide, you can gradually roll out new versions of services straight from GKE by using traffic splitting or canary deployments. Combined with backend service properties, this becomes a very flexible tool to migrate from version to version.

Let’s illustrate how the Kubernetes Gateway API simplifies traffic splitting across different services deployed in a cluster:

In this simple traffic splitting example, 90% of the traffic routed through the internal load balancer to store.example.com is directed to the store-v1 service and 10% of the traffic is sent to store-v2 service.

This can be achieved as simply as with the following manifest:

Looking ahead

Making the GKE Gateway controller generally available for single-cluster deployments is only a first step in our journey to create a real networking toolkit for platform administrators and service owners using GKE. Here are some other features that we’re working on. 

Multi-cluster Gateways

Within the next few months, we will continue our efforts to solidify our controller to ensure you can deploy a Gateway and Routes not just in a single cluster, but also in a multi-cluster environment (in Preview today). Using a multi-cluster Gateway across a fleet of GKE clusters will unleash new use cases including:

• Multi-cluster or multi-region redundancy and failover

• Low-latency serving through GKE clusters that have close proximity to clients

• Blue-green traffic shifting between clusters (try this tutorial)

• Expansion to multiple clusters because of organizational or security constraints

Multi-cluster Gateway, alongside multi-cluster Services, is a critical step forward for customers deploying global services who are seeking for more application availability without having to give up control over how the traffic is routed from one cluster to another.

New generation of Google Cloud load balancers

As mentioned earlier in this post, the GKE Gateway controller comes by default with two gateway classes — one for external load balancing and one for internal load balancing. Google Cloud recently announced the General Availability of the next generation of Global external HTTP(S) load balancers based on Envoy proxies. A new GatewayClass will soon be provided in the GKE Gateway controller to support this new load-balancing platform which provides advanced traffic management capabilities. We can’t wait to see what you build with these new load balancers within GKE.

Security 

When exposing services to the Internet, one of the first things that comes to mind is how to secure the platform and applications being exposed. Protecting the underlying infrastructure (the GKE nodes) is an obvious necessity that the GKE Gateway controller takes care of by managing the Cloud Firewall lifecycle for a given Gateway, but security is a multidimensional problem that must be tackled at different levels. In addition to the existing security features that the Gateway and the controller provide, we are continuing our effort to reinforce security for applications and will provide additional security features like SSL policies, HTTP redirects, Identity-Aware Proxy (IAP), and Cloud Armor.

Next steps

There’s a lot going on in the world of GKE Networking. At KubeCon North America, we presented 35+ sessions across the conference. Here are a few focused on Kubernetes Networking:

• Where did all my IPs go? Presented by Cynthia Thomas, Product Manager, Google Cloud

• Cilium Updates, News, Roadmaps, presented by Purvi Desai, Director of Engineering, Google Cloud and team 

• SIG-Network: Introduction and DeepDive - presented by Rob Scott and Bowie Du, Google Engineering

• Kubernetes Networking Infrastructure Offload - presented by Bloomberg, Intel, Nvidia, and Google

For more on Kubernetes Networking:

• Visit GKE Network Recipes for Gateway Demos

• Listen to the Podcast on Gateway Controller (from April 2022)

• Try it free of charge