Modular GKE Ingress with the Gateway API

Objective   

Gateway API for Kubernetes Ingress can handle a wider set of functionalities than that of original Kubernetes Ingress. In this blog we will have a look at the implementation of  Gateway on Google Kubernetes Engine(GKE). We will see how to initially set it up, and monitor it in GKE. We will also look at setting up some security in the form of a GCP Gateway Policy.

Introduction

NodePort and LoadBalancer service objects initially provided exposure of Kubernetes services to the outside world. Later, Ingress was developed, which routes traffic to services controlled by rules defined on the Ingress resource. The Kubernetes Gateway API is an evolution of Ingress, delivering the same function but as a superset of the Ingress capabilities. 

The GKE Gateway controller is Google’s implementation of the Gateway API for Load Balancing. The Gateway controller watches for Gateway API resources and reconciles Cloud Load Balancing resources to implement the networking behavior specified by the Gateway resources. The GKE Gateway controller supports multi-tenant usage of a load balancer, shared across Namespaces, clusters, and regions. 

With Gateway API, ingress implementation is broken into discrete resources including. This allows federation of components aligned with roles/teams. So, GatewayClasses are provided by the platform (see GatewayClasses on GKE). Cluster Operators provision a Gateway. Application teams can expose their applications by deploying HTTPRoutes independently and attaching them securely to the Gateway. See diagram below.

What do we want to do?

We want to set up external ingress to our sample web application running in GKE called twsttech.io using GKE Gateway. We need to:

create a global Gateway, based on the external L7 Gateway Class – referencing a certificate mapping

create a HTTPRoute, based on the root path to our application. 

create an SSL based GatewayPolicy to restrict tls to v1.2, referencing a previously generated SSL policy. 

We also want to understand a bit more about the specifications of the above resources and how they can be configured for use in different GKE ingress use cases. 

The following prerequisites are focused on ingress security rather than actual Gateway implementation and so are outside the scope of this blog:

Set the external domain name with static IP, 

Create a domain certificate

a certificate mapping created using Google Certificate manager 

An SSL policy to enforce tls version

Getting started

Let’s enable the Gateway API in our cluster. Ours is an existing GKE standard cluster, so we need to run the following command:

To enable the Gateway API on other GKE clusters types, follow the documentation Enable the Gateway API in your cluster.

Confirm that the Gateway classes are installed in your cluster:

Output should look like this (truncated for brevity):

Create external Gateway

Save the following manifest as gateway.yaml:

This file defines our Gateway with the following specifications:

Gateway is called op-gateway, created in the namespace ns-gateway

Gateway class is gke-l7-global-external-managed

Gateway is configured with the certificate mapping Certificate Manager wildcard-op-twsttech-io-cert-map which is applied via the annotation. This is a pre-configured certificate for the public domain *.twsttech.io. An advantage of Certificate Manager is the ability to use Google-managed certificates with DNS authorization for wildcard domain names

The gateway has listeners for both 80 and 443 , allowing bindings from all namespaces.

It also uses a pre-configured managed public ip, named twst-public-ip-op

Create a HTTPRoute

This will define the routes that we want to attach to the gateway.

Save the following manifest as httproute.yaml:

This file defines our HTTPRoute with the following specifications:

HTTPRoute name is training-route1-api

It references the Gateway – op-gateway ; and is created in the same namespace – ns-gateway. HTTPRoutes can be in different namespaces, using Shared Gateways 

Hostname is defined as training.twsttech.io.com with rules are set as the root path (/)

The BeckendRefs are defined as the GKE service being exposed, i.e. training

Create a GCPGatewayPolicy

This will allow us to customize our client to load balancer traffic with the minimum tls version. This references an SSL-based policy created previously.

Save the following manifest as gw-policy-tls.yaml:

This file defines our GCPGatewayPolicy with the following specifications:

The GCPGatewayPolicy is named gp-tls-12, in the same namespace ns-gateway as the Gateway.

The policy references a pre-configured SSL policy named sslp-tls-12

Deploy the files

Deploy all three yaml files using kubectl apply. Verify the all three have deployed:

Check that the gateway has an attached route:

And that’s it. Our sample web application in GKE is now exposed using Gateway API. We have specified the extra security of tls version also through the use of a Gateway policy.

Gateway API can be used for discrete or shared ingress routes. This gives the option of configuring a single load balancer with many routes which can save costs, as well as aligning with roles and teams within your organization. 

What’s next 

You can find the files used above in my opowbow github repo, feel free to have a look! Also, check out this video on Kubernetes Gateway to see it in action. For detailed information on deploying Gateway on GKE, go to the documentation page Deploying Gateways.